How to name Unit Tests

How should you name your Unit Tests? What standards should you have in place for their names?

Who cares.

I'm not going to tell you the exact structure and format you need to use. That's up to you, your company, your Technical Lead, or whoever thinks this is important.

What I'm here to tell you is there are certain things you should always do when naming Unit tests and that it is quite important that these things are done.

So what are these important things that you need to do when naming Unit tests?

They need to be named in a way that tells you what scenario they are testing and what the outcome should be. Seems obvious but there's a bit of an art to this, and it's very easy to do wrong.

Why is it important for unit tests to tell you what they do? It's because coding is a team sport. Code needs to be read and maintained. Unit Tests are code and they also serve as documentation of your functionality. More so sometimes, than the code itself.

Other people (including future you) need to be able to look at the names of the test and know what specifically is being tested. Not just the what, but the when. When does the thing that you're testing happen? What is specific to this particular scenario that makes it special?

An example of naming being done badly would be Verify_Process. What does verify actually mean, and what is the Process?

Oh, the method you're testing is called "SomethingProcess()"? Well that's a problem right there. Rename it to explain what exactly the "process" is doing!

Also, verify doesn't tell me anything. What are you verifying? What makes the thing you're testing “verified”? How is someone who looks at this code in 18 months going to know that by looking at this name? If they can't determine its purpose from the name they'll end up having to look through the code of the test, which is a considerably slower process.

Telling us just what the test does is also not enough. AddNewCustomerTest is not enough. What scenario are you testing? That a new customer can be added is not a scenario but an action. What about testing when a customer is not added successfully, for some reason, or when they are added but already exist?

Also, when are they being added? For example, you might name the test: WhenCustomerHasFullName_CustomerAddedSuccessfully. Here is a test which tests the scenario of when the customer's full name is included in the post. The name includes the scenario "When the Customer's full name is entered" and the expectation: "Customer Added Successfully".

Including the scenario is the critical part of your test name. It explains the conditions of the action you’re performing. "When I do this". "When this data is included". "When I try to access this as an administrator".

The expectation is your expected result. The outcome of the test. This is as critically important as the scenario. Together they form a combination explaining the reason the test exists. "When this happens, this should happen".

Some of you may be aware of the pattern "SystemUnderTest_When_Then" for naming tests. This is fine, and I would recommend this structure, but only because it includes the scenario and the expectation. System under test, or the thing that you're testing, is descriptive and useful of course, but it can be easily inferred by looking at the code (unlike the scenario; and expectations can usually be easily gleaned from the Assertions), and also, you could include this in the class name, tags, or some other descriptor.

It's the scenario and expectation that anyone looking at the tests wants to know. These are the critical parts of a test's name.

Getting this right not only means that your tests are easy to follow and understand, but it encourages you to think up more combinations. You can write these combinations of scenario/expectation out before you even complete the bodies of the tests. If you were to name a test "GetTimeZoneTest", or "FileProcessorTest" how would you do this?

It's worth noting too, that you can include everything I talk about here in Description Attributes, or Tests Cases, if that's preferred, over the Test name. The point is that it's clear what the tests are doing.

By including the scenario and the expectation in your test names/descriptions, it will encourage you to think like a tester. You will become concerned with why you are writing the tests, and learn to link scenarios with expectations.

It will also make your tests easy to read and forms helpful documentation for future maintainers.