97 Things Every Programmer Should Know

Chapter 95. Write Tests for People

Gerard Meszaros

YOU ARE WRITING AUTOMATED TESTS for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask, “Who am I writing the tests for?” If the answer is “For me, to save me the effort of fixing bugs” or “For the compiler, so they can be executed,” then the odds are you aren’t writing the best possible tests. So who should you be writing the tests for? For the person trying to understand your code.

Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario, the test(s):

• Describe the context, starting point, or preconditions that must be satisfied

• Illustrate how the software is invoked

• Describe the expected results or postconditions to be verified

Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests, and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause-and-effect relationship among these three parts.

This implies that what isn’t visible ...