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:
A more important drawback, is that by subclassing you are possibly changing the behavior of the superclass and invalidating your test results -- TimMackinnon
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.