commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <st...@apache.org>
Subject Re: RDF commons testing
Date Mon, 30 Jan 2017 10:20:46 GMT
On Mon, 30 Jan 2017 09:08:27 +1100, Peter Ansell <ansell.peter@gmail.com> wrote:
> Hi Claude,
> Abstract test classes are working well for Commons RDF so far. Others
> may benefit from your solution, so feel free to suggest the approach
> to others who may be interested in exploring it.

I would not dismiss Claude's suggestion out of hand. Apache Commons is
for anyone who wants to participate! :-)

Claude  - if you would like to have a go in a branch at what Commons RDF
tests look like using contract testing, then feel free!

>> https://www.linkedin.com/pulse/contract-testing-why-abstract-tests-enough-claude-warren-jr

I liked this blog article which explains the problem. We in a way
already have this problem twice in Commons RDF tests because we have the
Triple/Quad duality (TripleLike) and Graph/Dataset duality (GraphLike)
as well as the multiple implementations of the commons-rdf-api
interfaces.

So you will notice some of those tests have considerable duplication
with subtle differences, e.g. along the lines of:


    graph.add(triple);
    assertTrue(graph.contains(triple)
    assertTrue(graph.contains(triple.getSubject(),
        triple.getPredicate(), triple.getObject());

vs

    dataset.add(quad);
    assertTrue(dataset.contains(quad));
    assertTrue(dataset.contains(quad.getGraphName(),
      quad.getSubject(), quad.getPredicate(), quad.getObject());

This could in theory be harmonized so that there's a single abstract
test class with an abstract method to make the triple/quad - and then
extensions for Triple and Quad that adds the last decomposition
assertion.

But as we already use abstract classes to run the tests per RDF
implementation, and so I thought it would get messy to try to reorganize
it.


Another thing is that now the tests are munged together
into mainly AbstractRDFTest (which must create an RDF factory instance,
that then can create the other things) - otherwise you will have to
make many SomethingImplTest in each module (and easily forget to
specialize one of the tests in one of the modules)

With your approach, would you still have to make a such specialization,
or is that automatic?


BTW - in your approach, would it work to run the tests out of the box 
from an IDE like Eclipse? I think that is quite important so Commons RDF
can be maintainable by many people in Apache Commons.




-- 
Stian Soiland-Reyes
University of Manchester
http://www.esciencelab.org.uk/
http://orcid.org/0000-0001-9842-9718


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message