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:
Let’s look into a real world example:
In my previous team we used the following convention
Let’s see how the examples above would look like:
When there is only a happy path both naming conventions use the syntax:
Having naming conventions for tests has multiple advantages.
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.
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.
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