Craft Your Tests Well

Your test code is almost as important as your production code. Treat it as such. This means you should craft it to nearly the same standards as your production code. In particular, you should

• Be sure to express the intent of your test in its code

• Try to express only the intent and nothing more to the greatest extent possible

• Keep your test code simple and clean, using the same tools with nearly the same configuration and refactoring as you go

In the interest of keeping it simple, I will not repeat all of the other tenets of well-crafted code. You will want to apply some principles of software craftsmanship slightly differently, however.

Some static checker rules should be disabled for test code. For one, most static checkers do not know that assertions throw exceptions, so they do not treat them as terminal statements in a function or method. You may also find it acceptable to let the runtime environment tell you values are null or undefined in some tests rather than asserting their validity at all places.

The structure of a Four-Phase Test [xTP]—setup, execute, verify, and tear down—should be preserved regardless of refactoring. If you are more familiar with the AAA structure—arrange, act, and assert¹—then those are the boundaries to preserve. This means that you should not refactor across the phase boundaries. A little bit of repetition can better communicate the intent of the test.

1. Originated by Bill Wake in 2001, also known as AAA or 3A. See http://xp123.com/articles/3a-arrange-act-assert/.

A couple of other points deserve deeper treatment.