Listen to this post
As consultants, we are often asked to review the work of others. One of the things we review is the quality of the design of some part of the system. Is it cohesive, decoupled, non-redundant, encapsulated, open-closed, and so forth? Often the developers understand and agree that these qualities are important, but they are not certain they have achieved them adequately.
I often start like this, “I don’t know. Can you write a good test for it?”
I can ask this even before I look at their work because I know that bad designs are notoriously hard to test. It’s a great way to start an evaluation.
Of course, the trick to this is understanding what is meant by a “good” test.
In TDD, we focus on three specific aspects of tests, each of which I will post on separately in upcoming entries:
- The test must fail reliably for the reason intended.
- The test must never fail for any other reason.
- There must be no other test that fails for this reason.
These three statements describe an ideal, and of course in the real world they are not always perfectly achievable. But understanding “good” in this way helps to determine the design qualities mentioned above because, lacking them, writing “good” tests becomes increasing difficult.