Unit Test Naming Convention
I like Roy Osherove’s unit test naming convention:
[UnitOfWork_StateUnderTest_ExpectedBehavior]
A unit of work can be as small as a method or as large as (many) class(es) so long as it runs in memory is under our complete control. A unit of work is a use case in the system that starts with a public method and ends up with one of three result types:
- a return value/exception
- a state change to the system which changes its behavior
- a call to a third party (when using mocks)
So why should we name tests like this? First off, test names should express a specific requirement. This requirement is derived from a business or technical requirement, which is then broken down into small enough pieces, each of which represents a test case. Secondly, test names should include the expected input (or state) and the expected result for that input (or state). This clearly expresses the requirement of the test. It forces the developer to think about specific input variables (or current state) during the test and expected result from that state. Thirdly, test names should be presented as a statement or fact of life that expresses workflows and outputs. Unit tests are just as much about documentation as they are about testing functionality. They should be optimized for readability by the lucky bastard that will be reading over your tests in a year. He’s lucky because you followed this naming convention.
Examples:
Sum_NegativeNumberAs1stParam_ExceptionThrown
Sum_NegativeNumberAs2ndParam_ExceptionThrown
Sum_SimpleValues_Calculated
Generate_SimpleParameters_ReturnsDictionary
Parse_SimpleJson_ReturnsString
Now go forth, follow the naming convention, and be happy with your tests.
johnnylists