Chapter 4. Readability

Tests are the programmer’s way of expressing and validating assumptions and intended behavior of the code. Reading the tests for a given mass of code should provide the programmer with an understanding of what the code should do. Running those tests should tell the programmer what the code actually does.

Assertions play a key role in deciphering the behavior of code. Though all of the code that makes up a test tells a story about how the code under test is expected to behave, it’s the assertion statements that contribute the punchlines. It is the assertions that we study to be able to tell whether or not the code passes expectations. In a similar vein, the test framework uses those same assertions to check our assumptions during test execution.

Consequently many of the issues we discuss in this chapter revolve around assertions, but equally important for readability is all that other code in your tests—the code that arranges the fixture and the code that invokes or triggers actions on the code under test.

To summarize, in this chapter we’re focusing on a wide range of smells and problems with test code exhibiting undesirable properties. Those problems add cognitive load on the programmer, making it harder to read and understand the test’s intent and what it’s testing.

4.1. Primitive assertions

4.2. Hyperassertions

4.3. Bitwise assertions

4.4. Incidental details

4.5. Split personality

4.6. Split logic

4.7. Magic numbers

4.8. Setup sermon

4.9. Overprotective tests