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 <[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
