Question

I’m currently writing an implementation of a JDBC driver (yes, you read that correctly) in a TDD manner and while I have only finished class stubs at this point and only some minor functionality, it just occured to me that since Statement is a superclass for PreparedStatement which is a superclass for CallableStatement, what should I do when I really start to write tests for my implementations of those classes, which one of these should I do:

1. Create a test suite for Statement and then extend that suite for additional tests for PreparedStatement and then do the same for CallableStatement.
2. Test each implementation individually ignoring the methods inherited from superclass(es).
3. Rigorously test every single method individually for each implementation class; It is possible that some inherited methods work differently depending on implementation after all. Mild variation of this would be that I’d test all those inherited methods the implementation uses.

Number two feels the most natural but due to the reason I put to the third one I’m not that sure if it’d be wise to do so. So, what do you think I should do?

Answer 1

I would specifically never do alternative 1 (letting the test-class hierarchy be the same as the actual class hierarchy) if this means you will be running the same tests repeatedly for each test subclass. I am also generally sceptical of subclassing test classes other than the general utility base class.

I normally make 1 test for each class in a hierarchy, abstract or not. So the base class has a separate test (usually with a test-local private subclass that is used for testing it specifically), and I use my knowledge of the subclasses to write proper tests for each subclass. I can see in coverage runs what is missing tests, so I’m usually not too formalized up-front.