(^190) 97 Things Every Programmer Should Know
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 lead-
ing 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.