commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claude Warren <cla...@xenei.com>
Subject Re: RDF commons testing
Date Sun, 29 Jan 2017 16:11:57 GMT
Peter,

I have written a more detailed discussion of why abstract tests for
interfaces pose problems (
https://www.linkedin.com/pulse/contract-testing-why-abstract-tests-enough-claude-warren-jr).
I stand by my earlier assertions and offers.

Claude

On Sun, Jan 29, 2017 at 5:11 AM, Peter Ansell <ansell.peter@gmail.com>
wrote:

> On 28 January 2017 at 21:08, Claude Warren <claude@xenei.com> wrote:
> > I see that RDF Commons is listed as a set of interfaces to be implemented
> > on top of various RDF implementations.  I also see that there are
> abstract
> > tests for the interfaces.
> >
> > I would like to suggest that RDF commons look at using Junit Contract
> tests
> > (https://github.com/Claudenw/junit-contracts) which will ensure that
> tests
> > for all the implemented interfaces are run against the implementing
> classes.
> >
> > The strategy for junit-contracts is to create interface tests into which
> an
> > instance of the object being tested is injected.  Implementation test
> > suites are created by declaring the class under test and a mechanism to
> > create the instance of the class.  The contract-test junit runner then
> > locates all tests for all interfaces that are implemented by the class
> > under test and runs them (A dynamic suite if you will).
> >
> > As interface tests are developed they are automatically picked up by the
> > suites.  As interfaces are implemented by classes the suites
> automatically
> > pick up existing tests.  The maven plugins (and command line tools) will
> > report on the interfaces that don't have tests as well as classes that
> > don't have tests suites defined.
> >
> > Besides the convenience of the system finding the tests to run this
> > strategy has several other advantages:
> >
> > 1.  It allows classes that implement multiple interfaces to have one test
> > that tests them all.  Developers no longer have to track down abstract
> test
> > classes across multiple projects and create concrete implementations.
> >
> > 2.  It allows developers to quickly determine if their implementation
> > matches the full contract for the interface.
> >
> > 3.  It means that refactoring of parent interfaces / classes do not force
> > additional coding for the testing of derived classes.
> >
> > If you are interested I would be glad to help convert existing tests to
> > contract tests.
>
> Hi Claude,
>
> The existing abstract tests already fulfill the purposes you describe
> using the basic JUnit features.
>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message