9 Readability

 

This chapter covers

  • Naming conventions for unit tests
  • Writing readable tests

Without readability, the tests you write are almost meaningless to whoever reads them later on. Readability is the connecting thread between the person who wrote the test and the poor soul who must read it a few months or years later. Tests are stories you tell the next generation of programmers on a project. They allow a developer to see exactly what an application is made of and where it started.

This chapter is all about making sure the developers who come after you will be able to maintain the production code and the tests that you write. They’ll need to understand what they’re doing and where they should be doing it.

There are several facets to readability:

  • Naming unit tests
  • Naming variables
  • Separating asserts from actions
  • Setting up and tearing down

Let’s go through these one by one.

9.1 Naming unit tests

Naming standards are important because they give you comfortable rules and templates that outline what you should explain about the test. No matter how I order them, or what specific framework or language I am using, I try to make sure these three important pieces of information are present in the name of the test or in the structure of the file in which the test exists:

  • The entry point to the unit of work (or the name of the feature being tested)
  • The scenario under which you’re testing the entry point
  • The expected behavior of the exit point of the unit of work

9.2 Magic values and naming variables

9.3 Separating asserts from actions

9.4 Setting up and tearing down

Summary