In response to your points: 1) That code should be removed from the contract test unless we can figure out how to test dependsOn. it is there to remind me that problem needs to be solved or documented.
2) I thought I had pushed the snapshot up to the maven repository. I'll have to take a look at that. 3) @ContractImpl(...) should define the class under test. GraphMemPlain.class for example. The test runner looks at all the parent interfaces for the specified class and attempts to find contract tests for them. Not sure how to test that it is valid. I'll look into it. 4) The IProducer in the @ContractImpl() annotated class should be the same class as the @ContractImpl(). The reasoning is that while your tests currently implement Graph and it works fine now, once contract tests for InfGraph are created there may be an issue for BaseInfGraph where IProducer is used for the InfGraph tests. But then with type erasure it may not matter. The other reason for using the class under test for the IProducer parameter is that the @ContractImpl annotated class can have additional tests for the specific class. For example your GraphMemPlain test class could have additional tests that make use of the IProducer.newInstance() methods. This should simplify the direct class inheritance (as opposed to interface) testing. See https://svn.apache.org/repos/asf/jena/Experimental/new-test/src/test/java/com/hp/hpl/jena/graph/compose/MultiUnionTest.javafor an example. 5) I plan to shake it out a bit more. Your use helps in this. And release it as a MVN release before it goes into Jena production release. It is probably stable enough to do that now, but I would like to get a few more users banging on it first. I would consider contributing the code to a good home, so if you know of any project that might be interested let me know. Claude On Sun, Nov 3, 2013 at 7:39 PM, Andy Seaborne <[email protected]> wrote: > Claude, > > I tried it out and got something working. I was testing GraphMemPlain (in > ARQ) that is a term-equality graph used mainly for testing [5 failures] and > a graph from a TDB dataset [2 failures / 1.0.0 and green for 1.0.1-SNAPSHOT > because of the reported close bug, now fixed] > > A few points: > > 1/ What code should override this method? > > WARN testDependsOn should be overridden > > 2/ How should I have got binaries to work with? > > I git-cloned and built junit-contracts (after disabling the PGP - no > needed for a local install surely?). Then I svn-checkout'ed new-test but > when I build it with "mvn clean package" I get a jar of 7116 bytes. That > is way too small! > > Currently, I have the Eclipse project for new-test added to another > project to get the classes but that's a quick-and-dirty solution. > > 3/ @ContractImpl(...) > > It doesn't matter if you get the class wrong here! Shouldn't it be > checked? Or not necessary? As long it's a Graph class, not an interface, > it was working for me. > > 4/ IProducer<T> > > Should the generic IProducer be <Graph>, not the concrete implementation? > - this is the abstraction tested. Using <Graph> and it worked for me. > > 5/ What are the release plans for org.xenei:junit-contracts? > > Andy > > > On 27/10/13 11:58, Claude Warren wrote: > >> I have been working on new unit tests for the Jena project. I have >> completed a first pass on most of the core functionality. I would like a >> couple of developers to try out the new tests on their code as I would >> like >> some feedback before continuing much farther. >> >> These test classes use the junit-contracts framework ( >> https://github.com/Claudenw/junit-contracts) which uses annotations to >> identify test classes that are tests for interfaces (Contract tests) and >> executes them against concrete implementations of the interface. >> >> You can create a test for your graph implementation, called MyGraph in the >> example, by doing the following: >> >> import org.junit.runner.RunWith; >> import org.xenei.junit.contract.Contract; >> import org.xenei.junit.contract.ContractImpl; >> import org.xenei.junit.contract.ContractSuite; >> import org.xenei.junit.contract.IProducer; >> import com.hp.hpl.jena.testing_framework.AbstractGraphProducer; >> >> @RunWith(ContractSuite.class) >> @ContractImpl(MyGraph.class) // the class under test. >> public class MyGraphTest { >> >> // AbstractGraphProducer will automatically call close() on each graph >> when >> it is finished. >> // however if you have special clean up requriements will want to >> implement afterClose() >> // see AbstractGraphProducer class for more info >> protected IProducer<MyGraph> graphProducer = new >> AbstractGraphProducer<MyGraph>() { >> >> @Override >> protected MyGraph createNewGraph() { >> return new MyGraph(); // create a new instance of MyGraph here >> } >> >> }; >> >> @Contract.Inject >> public IProducer<MyGraph> getGraphProducer() { >> return graphProducer; >> } >> >> // additional MyGraph specific tests go here >> @Test >> public void myGraphSpecificTest1() { >> .... >> } >> >> } >> >> Since MyGraph implements Graph the GraphContractTest test methods will be >> added to the suite. >> >> The junit-contract suite handles locating contract tests for implemented >> interfaces and adding them to the suite. >> >> This should ensure that all implementation meet the contract requirements. >> >> For example whenever graph.add() is called the graph implementation should >> notify all the listeners. This is checked by the GraphContractTest. >> This >> solution should provide a simple means for developers to test their >> implementations. >> >> Currently the com.hp.hpl.jena.graph package and the >> com.hp.hpl.jena.rdf.model packages have tests. >> >> Much of the junit v3 test hierarchy is not in the new-test package. >> >> Claude >> >> > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
