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.pe...@gmail.com> wrote: > On 28 January 2017 at 21:08, Claude Warren <cla...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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
