I think that naming of tests includes three aspects:
- strategy - what’s the purpose of the names: should they reveal intent? should they help find a requirement in some document? …
- content - given the strategy chosen, what information do we need to put into the name of the test?
- style - upperCase_withSections, simply_separated_by_underscores, someOtherFormOfStyle, “Plain strings if the language and/or framework(s) supports this”
Patterns
There are various ways to name your (unit) tests. These are some of the more common patterns I’ve run across.
[UnitOfWork_StateUnderTest_ExpectedBehavior]
Kent Beck suggests:
-
One test fixture per ‘unit’ (class of your program). Test fixtures are classes themselves. The test fixture name should be:
[name of your ‘unit’]Tests
-
Test cases (the test fixture methods) have names like:
test[feature being tested]
Other patterns I’ve seen:
test_[RequirementsNumber]_[Osherove]
This makes it easy to track a failing test to its’ specification, if there is one. This could be a JIRA issue number or similar.
Statements:
when_adding_numbers_and_sum_is_greater_than_Integer_throw_exception() {