Hello Claude > Category testing requires that you know all the category tests when you write > your tests.>> The contract test finds all the implemented tests. So if we > implement a new test it is automatically picked up. Also the contract test > maven plugin will show us all the interfaces that are missing tests -- > actually the tooling will do that without the maven plugin. Thanks for clarifying. That makes sense, and also makes me want to experiment writing some contract tests. I'll spend some hours during the next days playing with the code in that GitHub repository :)
> I did some work awhile back to convert the tests to junit 4 (Under the > new-test branch) I couldn't find the branch under Jena's Git repo at ASF [1]. Maybe it was deleted? > The problem was the number of suites that are not supported by junit 4. >Many of the suites are written so that they add the tests at runtime so you >don't really know all the tests at compile time (as the annotations require). >I found (or wrote -- I don't recall which) an annotated suite that would allow >you to add tests are runtime -- I'll have to find that again. Oh, I also noticed it. This one test suite was the first one that I found [2] with this pattern. It would be great to have a procedure to follow when migrating these suites. > The secondary problem is that the number of tests is significant and it is > hard to keep up with newly added tests and changes as development proceeds. I can try helping with this. Maybe one or two long development cycles just to work on this issue. And maybe discuss in the mailing list on a coding style for new tests - and perhaps update the Wiki with some guideline. I've created a branch [3] to work on JENA-380. Feel free to commit to this branch too or to another branch. I'll try to keep it up to date to master and create one (or few) commits when merging to the master branch. Thanks!Bruno [1] https://git1-us-west.apache.org/repos/asf?p=jena.git;a=summary [2] https://github.com/apache/jena/blob/281e655a0cc696b76006a7bda0582662eefd98de/jena-iri/src/test/java/org/apache/jena/iri/TestExample.java#L226 [3] https://git1-us-west.apache.org/repos/asf?p=jena.git;a=shortlog;h=refs/heads/JENA-380 From: Claude Warren <cla...@xenei.com> To: Bruno P. Kinoshita <ki...@apache.org> Sent: Sunday, April 19, 2015 6:05 AM Subject: Re: Work on JENA-380 Category testing requires that you know all the category tests when you write your tests. The contract test finds all the implemented tests. So if we implement a new test it is automatically picked up. Also the contract test maven plugin will show us all the interfaces that are missing tests -- actually the tooling will do that without the maven plugin. I did some work awhile back to convert the tests to junit 4 (Under the new-test branch) The problem was the number of suites that are not supported by junit 4. Many of the suites are written so that they add the tests at runtime so you don't really know all the tests at compile time (as the annotations require). I found (or wrote -- I don't recall which) an annotated suite that would allow you to add tests are runtime -- I'll have to find that again. The secondary problem is that the number of tests is significant and it is hard to keep up with newly added tests and changes as development proceeds. Claude On Sat, Apr 18, 2015 at 1:10 PM, Bruno P. Kinoshita <ki...@apache.org> wrote: Hi Claude! > I would like to work with you on this. That's great! Shortly after writing I started to toy around with the existing tests. Looks like most of the code using JUnit3 that I found also have test suites. So probably simply finding "extends TestCase" and replacing by some annotations won't be enough. How do you think we can divide the tasks? I don't mind repetitive/manual tasks at all :-) > I also think that we should develop contract tests for our SPI interfaces > (like graph). That's new to me, and looks interesting. But just to see if I understand it correctly, couldn't we achieve the same with categories [1]? This way, tests for the interface "I" (from the example in the GitHub repo) could be orthogonally tested with a category CategoryI. And finally annotate a test suite class with @RunWith(Categories.class) @IncludeCategory(CategoryI.class) @SuiteClasses(...). What would be the advantage of the contract tests over using categories? CheersBruno [1] https://github.com/junit-team/junit/wiki/Categories From: Claude Warren <cla...@xenei.com> To: dev@jena.apache.org; Bruno P. Kinoshita <ki...@apache.org> Sent: Saturday, April 18, 2015 11:14 PM Subject: Re: Work on JENA-380 I was working on this awhile back and got pulled away. I would like to work with you on this. I also think that we should develop contract tests for our SPI interfaces (like graph). https://github.com/Claudenw/junit-contracts On Sat, Apr 18, 2015 at 9:55 AM, Bruno P. Kinoshita <ki...@apache.org> wrote: Hi all, I'm planning to work on JENA-380 [1], migrating tests from JUnit 3 to JUnit 4, and would like to know if anyone else is working on it. The issue includes some new structure for tests too, but I intend to simply remove the old JUnit 3 syntax (e.g. extends TestCase) by annotations. Later we can work on the remaining of the tasks or close the issue and open separate issues for each specific task. Any thoughts? Bruno [1] https://issues.apache.org/jira/browse/JENA-380 -- I like: Like Like - The likeliest place on the webLinkedIn: http://www.linkedin.com/in/claudewarren -- I like: Like Like - The likeliest place on the webLinkedIn: http://www.linkedin.com/in/claudewarren
