Menu
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:
Statement and then extend that suite for additional tests for PreparedStatement and then do the same for CallableStatement.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?
746
Whenever you're testing a subclass of your base class, have your test class inherit from your test superclass.
A subclass inherits all the members (fields, methods, and nested classes) from its superclass. Constructors are not members, so they are not inherited by subclasses, but the constructor of the superclass can be invoked from the subclass.
The answer is: always test only concrete classes; don't test abstract classes directly . The reason is that abstract classes are implementation details. From the client perspective, it doesn't matter how Student or Professor implement their GetSignature() methods.
The subclass inherits state and behavior in the form of variables and methods from its superclass. The subclass can just use the items inherited from its superclass as is, or the subclass can modify or override it.
"test every single method individually for each implementation class"
In particular, failure to override a superclass method properly is a common bug. The author of the subclass makes assumptions about the superclass. The superclass changes, and the subclass is now broken.
155
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
