Yep - I've done this sort of thing, and not just with tests. The trouble is that pretty soon I found myself nesting abstract classes and interfaces inside the nested classes, and then nesting more inside those, and then... well it ends up with the outermost class simply becoming a sort of super-package if you follow the process to its logical end. I think it reflects that the notion of "package" (at least as done in Java) has historically been a very weak one, and to some degree still is.
I think you're better off using JUnit's theories for this sort of thing.
I have used this when I had many implementations of an interface which have to behave the same externally but work differently inside. In fact, I used it to drive tests of different kinds of Lists (Array~, Linked~, My~) with Junit micro-benchmarks to compare performance. Worked out just fine for that case, but I wonder if it is a common scenario outside of collections classes. In my domain code, two objects which do the same thing would share code and not need duplicate tests.
1 reply
It has the advantage of keeping strongly related test classes closer together, which suggests higher cohesion. It also has the advantage of encouraging designers to keep contract tests separate from tests for implementation details.
I don't know either. I think it works well for the specific example here, but perhaps not for publishing contract tests for interfaces one wants others to implement.
I use contract tests almost everywhere I want an interface, but as Andreas points out, I'm not sure about this specific way to write them outside the context of a library intended for use rather than a library intended for customisation.
Nice, I like it. If the build tools and IDEs have no problems dealing with that, I'll try it the next time I use a contract test.
I wonder whether it would make the test class unmanageably big, when some of the implementations have lots of implementation-specific tests. For example https://github.com/orfjacka...
1 reply
It's just an idle thought; I haven't tried it "in anger" yet.
I wouldn't put the implementation-specific tests in the same class as the contract tests; indeed, that might be one of the points -- to separate those from each other.