I think there is a manifest parser in the example code... .but again, I would have to go looking for it.
On Mon, Apr 20, 2015 at 6:39 PM, Andy Seaborne <[email protected]> wrote: > PS > > Not directly relevant to jena-core but I'm testing out a Junit4 runner > that parsers manifest files. > > A lot of SPARQL testing is driven by RDF-based manifests, including the > material developed by the SPARQL working groups. > > > https://github.com/afs/mantis/tree/master/dboe-quack/src/test/java/org/seaborne/dboe/sparql > > This was on reason there is so much Junit3 but after a previous discussion > here with Claude, we looked at Junit4 based file parsing. > > Andy > > > On 20/04/15 17:40, Andy Seaborne wrote: > >> The nice thing is that there are two (semi-)independent strands: >> >> 1/ Direct Junit3 -> Junit4 update >> 2/ Improving the quality of tests with contracts. >> >> that means (2) can proceed at it's own natural pace. >> >> Andy >> >> >> On 20/04/15 07:28, Claude Warren wrote: >> >>> Here is the svn link to the earlier work. >>> https://svn.apache.org/viewvc/jena/Experimental/new-test/src/test/ >>> >>> note that all code is under the src/test branch. >>> note also that the old package names are in use. I think there is a move >>> to change the package names to org.apache.jena.... >>> >>> Claude >>> >>> On Mon, Apr 20, 2015 at 6:31 AM, Bruno P. Kinoshita <[email protected]> >>> wrote: >>> >>> 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 <[email protected]> >>>> *To:* Bruno P. Kinoshita <[email protected]> >>>> *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 <[email protected]> >>>> 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? >>>> >>>> Cheers >>>> Bruno >>>> >>>> [1] https://github.com/junit-team/junit/wiki/Categories >>>> >>>> ------------------------------ >>>> *From:* Claude Warren <[email protected]> >>>> *To:* [email protected]; Bruno P. Kinoshita <[email protected]> >>>> *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 <[email protected]> >>>> 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 web >>>> <http://like-like.xenei.com/> >>>> LinkedIn: http://www.linkedin.com/in/claudewarren >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> I like: Like Like - The likeliest place on the web >>>> <http://like-like.xenei.com/> >>>> LinkedIn: http://www.linkedin.com/in/claudewarren >>>> >>>> >>>> >>>> >>> >>> >> > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
