I’m working in an agile software development team which develops a fairly complex automation system for manufacturing facilities. We are using Test Driven Development as our main tool to improve the overall quality of the code. We all knew that we are going to have a large number of unit tests during the life cycle of the software. Before we started writing unit tests we decided that we need a test naming convention.
We agreed on the following naming schema:
Feature_PreCondition_Effect/PostCondition
Let’s look into a real world example:
SaveCustomer_WhenConcurrencyExceptionOccurs_ShouldRollbackTransaction StartMachine_WhenConnected_ShouldProcessLoadedProgram
In my previous team we used the following convention
FeatureWhenScenarioThenBehavior
Let’s see how the examples above would look like:
SaveCustomerWhenConcurrencyExceptionOccursThenRollbackTransaction StartMachineWhenConnectedThenProcessLoadedProgram
When there is only a happy path both naming conventions use the syntax:
Feature
Having naming conventions for tests has multiple advantages.
Similarity
The whole team agrees on a naming convention. No matter who wrote the test it is immediately clear what feature is tested under what scenario without even looking at the actual test code. This is also a huge advantage when new team members are introduced.
Grouping
Because the feature is leading the naming convention all tests concerning the same feature are alphabetically ordered in the unit test runner. All edge cases which are tested can be seen in the test runner just by looking at the test name.
Refactoring
High level refactoring such as moving a feature into another class can be done by just moving all tests concerning the feature into a fixture of that class.
In the new team I’m currently working we agreed to separate the feature from the when and then part with underscores. We think that after a long day of work it is clearer to read when separated with underscores in contracts to the camel cased syntax only. In the end it doesn’t matter which of the two test naming conventions you take, as long as the whole team agrees on it. But what really matters is that you have a test naming convention! Take my promise
HavingReadPlanetgeekBlogPostWhenAgreedOnTestNamingConventionThenDeveloperLifeEasier
and
HavingReadPlanetgeekBlogPost_WhenAgreedOnTestNamingConvention_ThenDeveloperLifeEasier
Hi Dani,
Good point to explain that having a naming convention for your tests is very important. The whole team just has to agree on it.
In the current team that I am coaching TDD we agreed on using the Feature_WhenPrecondition_ThenPostcondition schema. The people tend to understand their tests better. When writing a new test they reflect about what test they’re about to write and understand better what they really have to do.
Regards Phil
Thanks Dani for sharing this post. This is informative and interesting. I agree with you that test naming conventions are important. I have seen that Independent Software Testing Companies are very particular about this.