I wrote this

http://sourceforge.net/p/oriented/src/ci/master/tree/oriented/src-test/test/BetterParameterized.java

an example of its usage is:

http://sourceforge.net/p/oriented/src/ci/master/tree/oriented/src-test/test/TestExamples2.java

not sure if any of that is relevant, but if it is I am more than happy to 
change the license (currently GPL) for use in Jena …

That the way it may work for your problem is that the method annotated 
@Parameters would read the manifest and return a collection of arrays of things.
Each array is then used to initialized some tests (both with the constructor 
args, and to generate the test name with the method annotated @TestName)
and then for each one the tests annotated with @Test are run (I guess you may 
only have one of these)

Jeremy 

On Mar 24, 2014, at 3:30 AM, Andy Seaborne <[email protected]> wrote:

> Claude,
> 
> Seems like we arrived at similar places.  Extending ParentRunner<Runner> was 
> what I ended up with as well, after poking around the JUnit4 source code and 
> use of Eclipse to show the class hierarchy.  The documentation seems to be to 
> look at the code and, yes, "rather interesting" is an accurate description.
> 
> My scratch area is:
> 
> https://github.com/afs/quack/tree/master/src-dev/ju4
> 
> sometime, I'll clean it and move it to ARQ but nothing is actually broken 
> currently so it's not blockign anything.  I was reusing the tests elsewhere 
> and thought I'd update from Ju3 to Ju4.
> 
> What I'm looking at is processing W3C (RDF 1.1, SPARQL) test suites:
> 
> https://svn.apache.org/repos/asf/jena/trunk/jena-arq/testing/ARQ/manifest-arq.ttl
> 
> and aside from the fact the test suite for SPARQL is built by making SPARQL 
> queries (!),
> 
> The changes to ARQ over the weekend were from oddities that came up getting 
> the test suite to work with different mixes of manifests. Changing to/from 
> strict mode wasn't working - but that's really something only the test suite 
> has to worry about.
> 
>       Andy
> 
> On 24/03/14 07:30, Claude Warren wrote:
>> https://svn.apache.org/repos/asf/jena/Experimental/new-test/src/test/java/com/hp/hpl/jena/testing_framework/manifest
>> 
>> Has a manifest test annotation, a test runner and a test suite.  It looks
>> like it may use junit-contracts (
>> https://github.com/Claudenw/junit-contracts/) which may bite off more than
>> you want to chew.
>> 
>> Give me an example of the file and tests that you want to run and I'll take
>> a crack at them this evening.
>> 
>> Claude
>> 
>> 
>> On Sun, Mar 23, 2014 at 8:11 PM, Andy Seaborne <[email protected]> 
>> wrote:https://github.com/afs/quack/tree/master/src-dev/ju4
>> 
>>> Has anyone got experience of extending JUnit4?
>>> 
>>> I want to get rid of the usage of JUnit3-style TestSuite and TestCase.
>>> (Why? No reason other than an itch that using JUnit3 "junit.*" is old
>>> stuff.)
>>> 
>>> These are used in the scripted tests because a TestSuite can have variable
>>> number of tests and of variable type, a TestSuiet can contain a TestSuite.
>>> 
>>> The working group tests from DAWG, SPARQL-WG and RDF 1.1 are scripted with
>>> an RDF manifest file.  A manifest can refer to other manifests.
>>> 
>>> JUnit4 parameterized tests are not sufficient.  The best I got was to turn
>>> a single manifest into a parameterized test set, with one test 
>>> perhttps://github.com/afs/quack/tree/master/src-dev/ju4
>>> parameterization.  That makes naming messy (I got the class to have the
>>> right name but each class instance has one test called the 
>>> samehttps://github.com/afs/quack/tree/master/src-dev/ju4 thing (e.g.
>>> "test").  I could not see how to include @Parameterized inside a
>>> @Parameterized.
>>> 
>>> What I have ended up so far is having to implement a JUnit4 Runner,
>>> actually 3 of them, one to take class to pick out the annotations for the
>>> manifests and two variants for runner that is either a single scripted test
>>> and a test manifest runner including sub-manifests as a tree.
>>> 
>>> I know Junti4 is a testing "framework" but I feel I have had to write a
>>> lot of machinery for what was in JUnit3 quite simple.  I get the feeling
>>> I've missed something somewhere.
>>> 
>>> Any ideas?
>>> 
>>>         Andy
>>> 
>> 
>> 
>> 
> 

Reply via email to