A large part of this mass of tests is for their 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
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
Features 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
- 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.)