Why test naming conventions are important!

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




About the author

Daniel Marbach


  • 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.

Recent Posts