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.