On 04/11/13 09:13, Claude Warren wrote:
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.
If it depends on org.xenei.*, then it can't be deployed?
It does not explain why I get a 7K byte jar file after the successful
build. I had org.xenei:junit-contracts locally installed and when I did
"mvn package" in o.a.j:new-tests I got something way too small (it had
no classes in it!!).
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.
My understanding is that you give it a class and the code finds all
contracts that it knowns how to test for that class.
Thought: Would it be useful to be able to explicitly name the contract
to be tested? It would be natural if it worked for an interface.
I-the-developer may wish to test one aspect/contract of my class but not
yet another. Or control the order of testing; I prefer to test the
basics first, then test combinations.
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.
Your call, but I'm happy for Jena to publish it's own infrastructure.
This is the quickest route, with least friction.
Long term it would be good to split out; it's just that it is a longer
path and may hold up our own use of it.
(this is true of other things as well - e.g. TDB's B+Trees c.f. Apache
Directory Mavibot)
Andy
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
