Unit test naming conventions

Working on a larger code base with many developers it can be a good idea to lay out some naming convention for the unit tests in the project upfront. The following is some of my own opinions about this topic — but they all are inspired from other people in the industry.

Test method names

I prefer to use the style suggested by Roy Osherove. He suggest that you split the test method name into three parts separated with underscore:


MethodName is the name of the method you are writing test against. In the small example below this would be Add

StateUnderTest is the state before running the test. This could be PositiveNumbers indicating that we are adding positive numbers.

ExpectedBehavior is the expected result of running the test. In the example above that could be AddNumbers.

This would end up with the full method name as follows:

public void Add_PositiveNumbers_AddNumbers() {...}

The advantage of this naming convention is that is makes it clear to the next developer what this test is supposed to test.

Triple-A + T

I commonly split my test method into four phases. The first three phases are well known and follows the arrange, act, assert phases. The maybe not so common last phase is the TearDown phase.

In the arrange phase you setup your state before running the test. This phase can be quite large and this can indicate a code smell. Luckily there is libraries out there that help with reducing this phase. In .net the library AutoFixture is super helpful for reducing the noise of the arrange phase.

The act phase is where you execute your test again the system under test. This phase is typically relative small.

assert phase is where you verify that the behavior meet the expectation. It is a good practice to only have one assert per test method. The benefit is that your test can only fail for one reason. Most unit testing frameworks allow you to add a friendly error message if the test should fail. This is something I would recommend to look out for in code reviews.

Last in the teardown phase you clean up any managed resources after the test has run. This phase it not so commonly used but is suggested in the book xUnit test patterns by Gerard Meszaros.

System under test, actual and expected

I like to use the same names for variables across tests. This helps with readability for other developers.

I always call the unit I want to test for sut this is an acronym for system under test.

The result of excising the system under test I name actual — this makes it clear that this is the result of running the test. I compare actual against the expected value. I typically declare expected as part of the arrange phase.

The simple sample below show it all in action:


Adopting simple naming conventions like this can make a test code base easier for all developers to read and understand.

Treating your test code as a first class citizen is important as unmaintainable code will soon decay and worst case be skipped — loosing its value.

Ideally a tool would check for these naming conventions — but if that is not possible code reviews should include checking for such things.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.