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
