You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Claude Warren <cl...@xenei.com> on 2013/10/27 12:58:56 UTC
New unit tests
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
Re: New unit tests
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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
>>>
>>>
>>
>
>
Re: New unit tests
Posted by Claude Warren <cl...@xenei.com>.
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 <an...@apache.org> 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
Re: New unit tests
Posted by Claude Warren <cl...@xenei.com>.
I finally got back around to looking at the test errors. It looks like
GraphMemPlain capabilities report that it implements literal typing but
does appear to actually do so.
On Sun, Nov 3, 2013 at 7:39 PM, Andy Seaborne <an...@apache.org> 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
Re: New unit tests
Posted by Andy Seaborne <an...@apache.org>.
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
>