Abstract classes in languages like Java or C# serve two purposes: they create polymorphism in design, and they are a convenient place to put behavior that is common to all derived classes, avoiding redundancy.
But if all behavior in TDD needs to be tested, and if instance behavior implemented in abstract classes cannot be tested (because they cannot be instantiated), then how can we adhere to our process?
Abstract classes have subclasses. An instance of any one of those subclasses will have access to the common behavior implemented in the abstract base class, so the developer could simply pick any one of them and test the common behavior using it. The problem with this is that it couples the test of the common behavior to a specific subclass, which is not preferred.
This is another use for a kind of mock: a subclass is created only for testing. It is part of the test suite, not a public class, and is specifically designed to be convenient for testing. This is also called a “testing adapter” and is a best practice in TDD. Not only does it decouple the test from other implementations, it can be crafted to make it easier to test (adding public methods that call protected ones, for example).
-AMAZONPOLLY-ONLYAUDIO-START-
This is Scott Bain. Visit us at www.netobjectives.com.
-AMAZONPOLLY-ONLYAUDIO-END-