How many times have you run your tests, gotten a failure, and had to go digging through the test code to try to understand what it’s complaining about? For many of you, you’re so used to doing this that you don’t even notice it’s a problem.
Every time you have to read test code, precious time is lost. The feedback cycle lengthens, and you’re breaking your stride.
Remember, we are trying to go for fast feedback. When I run unit tests and get a failure, I want to understand what I just broke. And I want to do this without reading the test code.
Ideally, the test name alone gives me the information I need.
Poor test names
Consider a test named “testCalculateSalary”. Simple names like this are common in unit test tutorials, but I can’t recommend them in real code.
If this test fails, what do we know? We know that something has gone wrong in salary calculation. But beyond that, we can’t tell without looking.
- Which path through salary calculation failed?
- What type of employee was it?
- Was there anything unusual about the chosen date range?
So many questions we can’t answer without digging into the test code, and possibly the production code as well!
Good test names: three elements
Instead, let’s put more information into the test name. When a test fails, I want to know three things:
- What is being tested
- Under what circumstances
- What is the expected result
Roy Osherove, author of The Art of Unit Testing, provides a good unit test naming convention that incorporates these three elements. In his blog post “Naming standards for unit tests” he describes it thus:
I have adopted this naming convention, with slight changes:
- XCTest lacks a way to annotate test methods. So we still have to start with a “test” prefix, followed by the “unit of work” part.
- I usually begin the “state under test” part with the prefix “With”.
- I usually begin the “expected behavior” part with the prefix “Should”.
All told, I apply Roy Osherove’s template to yield test names that look like this:
It may look odd to combine camel casing with underscores. Though unusual, I like how the underscores clearly separate the test name into its three components.
My test names don’t follow this template slavishly. If the unit of work is obvious (from the name of the test class), I may omit it. If the expected behavior is obvious, I may omit it. But whether explicit or implied, the three elements must be present without guesswork.
Pick a naming convention that works for you
Whatever naming convention you choose, try to communicate the three parts. It may feel overly verbose, but there’s nothing wrong with having really long test names, as long as they’re clear.
How do you like to name your tests? Can you find any poorly named tests in your suite? Click here to share in the comments.