A large part of this mass of tests is for the Guava collection implementations. They've written generic tests that exhaustively test the collection interfaces, and this generates a suite per implementation. See, for example, classes called CollectionAddAllTester
, ListIndexOfTester
.
This is all backed by a library called testlib, which ships as part of Guava. This is quite generic. It supports writing generic tests for any interface (not just collections). You can specify Feature
s of possible implementations and test those (e.g. if your set is unmodifiable you expect a different outcome from set.add()
), and when you run the tests you specify which features your implementation supports.
It's based on JUnit 3, not 4. Normally, you have a class extending TestCase
full of methods named testSomething()
, and JUnit runs them reflectively. The testlib library hooks into the running of these tests so that the lifecycle looks like this:
- For each implementation you want to test
- For each (applicable) test method
- Create the
TestCase
instance
- Initialise the
TestSubjectGenerator
– this is the testlib interface that you extend where you actually create the test subject
- Reflectively run the test method. During this method,
getSubjectGenerator()
gives access to the test subject
The key bit is the extra initialisation step that allows them to inject a specific test subject into the generic test case.
I wrote a post on how to write testlib generating suites for your own interfaces.
(Also posted to the same question on the sqa site.)