97 Things Every Programmer Should Know

(Chris Devlin) #1

(^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.

Free download pdf