Tell me what to expect
Working with a large code base, you get to see many different styles of unit testing. One of the aspects that I find interesting is the naming of the test methods.
Below are some examples of styles that I often come across. For the example, I use a hypothetical parser which is given an empty string as input.
testParse()
testParse_EmptyString()
testParseEmptyString()
parseEmptyString()
While all of these have their pros and cons, my primary objection is one they all share – they don’t tell me what should happen! They are as informative as writing assertEquals(actual)
rather than assertEquals(expected, actual)
. I want to see something along the lines of these.
parseEmptyStringShouldReturnEmptyDocument()
testParse_EmptyString_EmptyDocument()
parsingAnEmptyStringReturnsAnEmptyDocument()
These variants tell me not only what the stimulus is, but also the expected outcome. I want it both. Stimulus and response. Input and output. Initial state and resulting behavior.
Another way to see it is that the tests become a requirement specification for the implementation. One could actually write the corresponding implementation code based on the latter test names, try doing that from the first ones.
Updates #
- 2024-04-24: Republished this post which was originally written for my previous blog.