You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2014/03/23 21:11:46 UTC
Help with JUnit4?
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 per
parameterization. That makes naming messy (I got the class to have the
right name but each class instance has one test called the same 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
Re: Help with JUnit4?
Posted by Claude Warren <cl...@xenei.com>.
Andy,
I did a manifest runner in the new-tests project. I'll have to go looking
for it but I recall doing it. I think it took a manifest and ran it.
Though it may have been a specific instance of manifest.
The internals of Junit4 are rather interesting and seemingly convoluted.
Claude
On Sun, Mar 23, 2014 at 8:11 PM, Andy Seaborne <an...@apache.org> wrote:
> 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 per
> parameterization. That makes naming messy (I got the class to have the
> right name but each class instance has one test called the same 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
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Help with JUnit4?
Posted by Andy Seaborne <an...@apache.org>.
On 28/03/14 21:14, Claude Warren wrote:
> The issue with junit4 is that the suite definition is in an annotation and
> therefore has to be defined at compile time, so there is no mechanism to
> define tests at runtime.
>
> manifest based code I did attempted to provide a mechanism to create the
> tests are runtime. Perhaps there is a common point here such that we can
> build an annotation suite that will allow identification of a test suite
> using annotations but delay the creation of the tests until runtime so that
> further configuration can be applied.
>
> Thoughts?
What I've is name the manifest file in the annotations,
@RunWith(RunnerSPARQL.class)
@Label("SPARQL [main]") // A display name.
@Manifests
({
".../sparql11-test-suite/manifest-arq-sparql11.ttl",
"../ARQ/Serialization/manifest.ttl"
})
The manifests are W3C format and can include other manifests. They also
include manifest names and test names. Not Java specific and the test
suite was used by all implementation reports. Much the same approach is
used for RDF 1.1.
The RunnerSPARQL picks up the annotations at runtime and builds the test
tree. Most of the code is SPARQL test specific.
Aside from the recursive fact that paring the manifests is done with
SPARQL to build the SPARQL test suite ... (and when it fails there is a
risk of a green line on less than all the tests!)
There is some sort of common point in the tree of tests, both you and
Jeremy have similar structures. It isn't huge though.
Andy
>
> Claude
>
>
> On Thu, Mar 27, 2014 at 4:49 PM, Jeremy J Carroll <jj...@syapse.com> wrote:
>
>>
>>
>> On Mar 26, 2014, at 2:21 PM, Andy Seaborne <an...@apache.org> wrote:
>>
>>> We (you, me, jeremy) seem to have ended up in a similar place.
>>
>>
>> I have used junit4 for quite a bit now, but I definitely like the ability
>> to define my own test suites programmatically, (which is needed for your
>> use case) and the Parameterized Test Runner that comes built-in is close
>> but not close enough; hence I roll my own
>>
>>
>>
>
>
Re: Help with JUnit4?
Posted by Claude Warren <cl...@xenei.com>.
The issue with junit4 is that the suite definition is in an annotation and
therefore has to be defined at compile time, so there is no mechanism to
define tests at runtime.
manifest based code I did attempted to provide a mechanism to create the
tests are runtime. Perhaps there is a common point here such that we can
build an annotation suite that will allow identification of a test suite
using annotations but delay the creation of the tests until runtime so that
further configuration can be applied.
Thoughts?
Claude
On Thu, Mar 27, 2014 at 4:49 PM, Jeremy J Carroll <jj...@syapse.com> wrote:
>
>
> On Mar 26, 2014, at 2:21 PM, Andy Seaborne <an...@apache.org> wrote:
>
> > We (you, me, jeremy) seem to have ended up in a similar place.
>
>
> I have used junit4 for quite a bit now, but I definitely like the ability
> to define my own test suites programmatically, (which is needed for your
> use case) and the Parameterized Test Runner that comes built-in is close
> but not close enough; hence I roll my own
>
>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Help with JUnit4?
Posted by Jeremy J Carroll <jj...@syapse.com>.
On Mar 26, 2014, at 2:21 PM, Andy Seaborne <an...@apache.org> wrote:
> We (you, me, jeremy) seem to have ended up in a similar place.
I have used junit4 for quite a bit now, but I definitely like the ability to define my own test suites programmatically, (which is needed for your use case) and the Parameterized Test Runner that comes built-in is close but not close enough; hence I roll my own
Re: Help with JUnit4?
Posted by Andy Seaborne <an...@apache.org>.
On 26/03/14 21:01, Claude Warren wrote:
> Andy,
>
> Sorry - I got buried at work. Would you like me to look at running the
> tests in question with the new tests or do you have a solution already done.
Thanks and quite understandable.
I have a solution, and it works so far - I'd like to understand the
internals of JUnit4 better but, realistically, the list of things I'd
like to understand better seems to grow over time.
It's not a blocker and I'll see if the solution works for Quack/Lizard
testing. The current ARQ test code works to writing it "better" isn't
urgent in anyway and it would only disturb it speculatively .
We (you, me, jeremy) seem to have ended up in a similar place. That's
reassuring to me that I haven't missed the obvious.
Andy
>
> Claude
>
>
> On Mon, Mar 24, 2014 at 10:30 AM, Andy Seaborne <an...@apache.org> 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 <an...@apache.org> 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
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
Re: Help with JUnit4?
Posted by Claude Warren <cl...@xenei.com>.
Andy,
Sorry - I got buried at work. Would you like me to look at running the
tests in question with the new tests or do you have a solution already done.
Claude
On Mon, Mar 24, 2014 at 10:30 AM, Andy Seaborne <an...@apache.org> 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 <an...@apache.org> 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
>>>
>>>
>>
>>
>>
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Help with JUnit4?
Posted by Jeremy Carroll <jj...@gmail.com>.
On Mar 26, 2014, at 12:37 PM, Jeremy Carroll <jj...@gmail.com> wrote:
> I wrote this
>
> http://sourceforge.net/p/oriented/src/ci/master/tree/oriented/src-test/test/BetterParameterized.java
That overstates what I did. I did not like the built-in Parameterized which names the tests 1, 2, 3 etc.
Unfortunately modifying it in an elegant way proved difficult, and this modification involves some copy/paste :(
Re: Help with JUnit4?
Posted by Jeremy Carroll <jj...@gmail.com>.
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 <an...@apache.org> 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 <an...@apache.org> 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
>>>
>>
>>
>>
>
Re: Help with JUnit4?
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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
>>
>
>
>
Re: Help with JUnit4?
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@apache.org> wrote:
> 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 per
> parameterization. That makes naming messy (I got the class to have the
> right name but each class instance has one test called the same 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
>
--
I like: Like Like - The likeliest place on the web<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren