commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ansell <ansell.pe...@gmail.com>
Subject Re: RDF commons testing
Date Sun, 29 Jan 2017 22:08:27 GMT
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.

Cheers,

Peter

On 30 January 2017 at 03:11, Claude Warren <claude@xenei.com> wrote:
> 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

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


Mime
View raw message