Test Naming Conventions With Unit of Work

When I name my tests I use the name of the “unit of work” as the first part. If the unit of work is bigger than a method, I usually name the test with the name of the initial public method that starts the unit of work. 

Test names are affected by the type of end result we are expecting. So a test might look like this for a return value result:

IsLoginOK_UserDoesNotExist_ReturnsFalse

or like this for a state change result:

AddUser_ValidUserDetails_UserCanBeLoggedIn

or like this for 3rd party end results (when we use mock objects):

IsLoginOK_LoginFails_CallsLogger

the first part is the unit of work. the second part is the scenario. the third part is the expected end result or behavior of the system.

Comments

[Chris Oldwod]

I find this kind of naming style too terse for tests. Kevlin Henney suggests that the test name is a proposition, which when viewed as a collection can be seen as an executable specification of sorts. By taking a leaf out of the BDD naming convention book (given/when/then) you can make things much more readable and easier to write in the first place, e.g.

IsLoginOK_ShouldReturnFalse_WhenUserDoesNotExist

AddUser_ShouldAllowUserToBeLoggedIn_WhenValidUserDetails

IsLoginOK_WhenLoginFails_ShouldCallLogger

I personally favour the <Feature>_<Should>_<When> order as it's the scenario that often varies subtly, rather than the outcome. Also, liberal use of underscores should not be underestimated to aid readability of lengthy test names, e.g.

IsLoginOK_should_return_false_when_user_does_not_exist