Previous Lecture Complete and continue  

  Why I Don't Consider Subclass to Test An Anti-Pattern

How do we reconcile “Don’t mock what you are testing” and the Subclass to Test technique? In short, I use Subclass to Test in order to start moving in the direction of the design I want without making a significant commitment to moving in that direction. This way I tend to avoid many of the chain-reaction refactorings that I tend to find in legacy code, so I avoid the distraction of wanting to make those changes while I’m trying to focus on this one. I see Subclass to Test as a necessarily evil on the path towards a more cohesive design.

Since I prefer not to mock part of a module in order to test another part of it, when I do this, it acts like a big comment reading, “Don’t stop here. Continue improving the design.” I use Subclass to Test in order to no longer need to use Subclass to Test. I mock part of a module in order to know which parts to separate from each other with the goal of no longer mocking one part in order to test another.

Finally, I should note that mocking part of a module to test another part of it doesn’t always lead to trouble. I consider it a risk, but not always a problem. I sometimes make the conscious choice to let this happen. Even so, I tend to consider all legacy code “guilty until proven innocent”.

References

Stack Overflow, UnitTesting: Is “Subclass and override” technique considered to be a “bad practice”?. The question that I answer here.