Every test should justify its existence. You might think that if tests are good, then more tests are better, but that’s usually not the case. Extra tests that are truly redundant are dead weight in the test suite. They are a drag on agile development not only in slowing down the test suite, but they can also slow future development — they are extra tests that have to be changed as the application’s requirements change. (Integration tests or end-to-end tests are an exception to this rule.)
For example, let’s imagine that we have an AbstractFlyable and its subclasses, Blimp, Helicopter, and Airplane. To the extent that there is testable functionality in AbstractFlyable – maybe calculations related to speed or fuel consumption — we test those in AbstractFlyableTest. There’s really no good reason to re-test those capabilities in BlimpTest. BlimpTest should be testing the code that is blimp-specific.
This rule is often violated when frameworks are used. For example, it’s common for a web application to have a persistence framework hiding SQL usage underneath, and to be used repeatedly for storing all kinds of data for our application, whether blimps, repair parts, departure dates, or whatever. For each of these, we want to test the code that is specific to each use of the framework.
- Do test that blimps are something persisted to the database.
- Do test specialized queries created just for blimps, such as a complex query to allow blimps to find football stadiums.
- Don’t test behavior that is inherited from the framework, such as the ability to compute air speed from data persisted by all AbstractFlyables.
In some of the more rigorous forms of TDD such as ping pong TDD or devil’s advocate testing (forthcoming blog post), a natural rhythm emerges:
- The developers imagine some piece of functionality they want to add to the code.
- They write a test that pushes them in the right direction.
- They implement as little production code as they can to get the test to pass.
- And then they iterate this cycle until done.
Done right, no production code is created without a corresponding test. But another, less obvious, advantage is that no tests are created without corresponding production code. No tests is added unless it is needed to drive development. As a result, the test code stays lean. This is harder to do if tests are written en masse before or after the production code.
Like your production code, your tests should be lean. And fast. J-E-T. Justify every test.
