Kevin Rohrbaugh

Like many developers, when I first started writing unit tests, I didn’t approach it with much discipline. It’s just test code, after all; no user is going to look at it. This led me to write test methods like this:

[Test]
public void IdTest()
{
    // Test code here
}

It’s easy to see how woefully inadequate this naming structure is, not to mention that appending “Test” to the end of every test method (when it already has an attribute declaring as much) is obnoxious. When I wrote unit tests like this, I typically used my unit tests (which often ended up actually being integration tests) only until I had a functional UI and then reverted to browser-based manual testing.

Flash forward to the present, where I make sure that all my unit test methods are named using a pattern that I’ve picked up from the likes of Roy Osherove and others:

[Test]
public void MethodUnderTest_ExpectedResult_GivenCondition()
{
    // Test code here
}

Using this convention, each part of the test method name carries specific information:

• MethodUnderTest: Specifies what method of the test class we’re exercising, scoping the test to a specific aspect of the class being tested.
• ExpectedResult: Specifies what the test expects the results of calling the MethodUnderTest should be and scopes what our asserts for the test will be checking.
• GivenCondition: Outlines the environmental or argument conditions that the test should run within.

All three elements of this naming structure help to tightly define what it is that the test should be doing. This is critical as the primary consumer of unit tests is almost always the future developer, not the present one. In other words, we write unit tests to help us today, but a lot of their benefit comes when we make changes to the application in the future and can prove that individual components still work after those changes are implemented. If you’re like most people, using a test method naming convention that serves as a cheat sheet for what you were thinking when you wrote the test six months ago will come in handy and help make sure you preserve the intent of that test if/when it starts to fail.

Here’s an example of a real unit test using the naming convention:

[Fact]
public void Go_RedirectsToIndex_WithEmptySearchTerm()
{
    var searchTerms = string.Empty;

    var result = Controller.Go(searchTerms);

    var actionName =
        result.AssertActionRedirect().RouteValues["action"].ToString();
    Assert.Equal("Index", actionName, StringComparer.InvariantCultureIgnoreCase);
}

It seems like such a simple thing to adhere to, but it’s made a world of difference in my test maintainability. It’s even made it easier to write tests, since the naming convention makes me think critically about what I’m trying to test. It’s great when a little change like this makes such a big impact on my day-to-day development.