Subclass To Test

Subclass to test is a cool idea invented by BillTrost. I've adopted it as a method of TacticalTesting (thanks Bill). The idea is that by subclassing a class, you can get access to its protected (and presumably package protected, since you are the developer and hence can add code to the same package) methods in order to test them.

The benefits of this approach are: The drawbacks are: -- JohnFarrell

A more important drawback, is that by subclassing you are possibly changing the behavior of the superclass and invalidating your test results -- TimMackinnon

Patient
Doctor, doctor, it hurts every time I do this! [patient grabs elbow and twists violently]

Doctor
Don't do that.

Sorry, but if you do that, aren't you just being clumsy (not that I am ever clumsy...) -- BillTrost

I prefer the technique suggested in the JUnit FAQ (at least the one that comes with JUnit3.2 for Java). There, you duplicate your package structure in a separate test directory that you put in your class path. This way you can use both package and protected-access variables and methods without having to subclass and you don't have to worry about polluting your package name space either. -- Scott Langley

See SubclassToTestAntiPattern.


[In response to some AbstractTest comments that were moved to that page...]

SubclassToTest is not for perfect class hierarchies. In less than perfect hierarchies, often you have dependencies on things that either make your setup very difficult (for example, direct database calls) or things that make your tests take a long time to run (roundtripping on a network for instance). I don't mind violating encapsulation on a class that is hiding too much. Often it is the first step towards making things better. -- MichaelFeathers


See SubclassToTestDiscussion. Contrast AbstractTest.
CategoryTesting

EditText of this page (last edited July 24, 2008) or FindPage with title or text search