Naming Conventions for Unit Tests

Question

What are some popular naming conventions for Unit Tests?

General

• Follow the same standards for all tests.
• Be clear about what each test state is.
• Be specific about the expected behavior.

Examples

1) MethodName_StateUnderTest_ExpectedBehavior

Public void Sum_NegativeNumberAs1stParam_ExceptionThrown() 

Public void Sum_NegativeNumberAs2ndParam_ExceptionThrown () 

Public void Sum_simpleValues_Calculated ()

source: http://weblogs.asp.net/rosherove/archive/2005/04/03/TestNamingStandards.aspx

2) Separating Each Word By Underscore

Public void Sum_Negative_Number_As_1st_Param_Exception_Thrown() 

Public void Sum_Negative_Number_As_2nd_Param_Exception_Thrown () 

Public void Sum_Simple_Values_Calculated ()

Other

• End method names with Test
• Start method names with class name

Answer 1

See Behavior Driven Development.

Answer 2

I would say that you should follow the same conventions as used for the rest of the methods. The only rules that I tend to follow are:

1. The class name ends with Test - ClassTestedTest
2. A test method name is clear as to its intent - TestAdd

Trying to put all the expected output on the test method name can cause it hard to read or maintain. For example if you change something that in a sudden changes the output and you do not update the name of the method this can cause confusion. Most common TDD frameworks allow to add a description on the method to overcome this issue and state clearly the test method intent.

Answer 3

As long as you follow a single practice, it doesn't really matter. Generally, I write a single unit test for a method that covers all the variations for a method (I have simple methods;) and then write more complex sets of tests for methods that require it. My naming structure is thus usually test (a holdover from JUnit 3).

Answer 4

The first set of names is more readable to me, since the CamelCasing separates words and the underbars separate parts of the naming scheme.

I also tend to include "Test" somewhere, either in the function name or the enclosing namespace or class.

Answer 5

And oh, I don't mix my test code with my production code. As you state its Test code so who cares what you name it, except I guess you did, even though two others said to put "test" into their name convention. Thanks Rob for taking a one line asnwer and assuming that I am some kind of nut case programmer. I understand your theory on why to down vote a noobs comments, but don't understand why you felt it necessary to attack my integrity as a developer.

"I usually put Test_ in front of the method name, and then If I need multiple tests for the same method, I put some sort of explanation at the end of the method. "

Answer 6

I am pretty much with you on this one man. The naming conventions you have used are:

• Clear about what each test state is.
• Specific about the expected behaviour.

What more do you need from a test name?

Contrary to Ray's answer I don't think the Test prefix is necessary. It's test code, we know that. If you need to do this to identify the code, then you have bigger problems, your test code should not be mixed up with your production code.

As for length and use of underscore, its test code, who the hell cares? Only you and your team will see it, so long as it is readable, and clear about what the test is doing, carry on! :)

That said, I am still quite new to testing and blogging my adventures with it :)

Answer 7

I do name my test methods like other methods using "PascalCasing" without any underscores or separators. I leave the postfix Test for the method out, cause it adds no value. That the method is a test method is indicated by the attribute TestMethod.

[TestMethod]
public void CanCountAllItems() {
  // Test the total count of items in collection.
}

Due to the fact that each Test class should only test one other class i leave the name of the class out of the method name. The name of the class that contains the test methods is named like the class under test with the postfix "Tests".

[TestClass]
public class SuperCollectionTests(){
    // Any test methods that test the class SuperCollection
}

For methods that test for exceptions or actions that are not possible, i prefix the test method with the word Cannot.

[TestMethod]
[ExpectedException(typeOf(ArgumentException))]
public void CannotAddSameObjectAgain() {
  // Cannot add the same object again to the collection.
}

My naming convension are base on the article "TDD Tips: Test Naming Conventions & Guidelines" of Bryan Cook. I found this article very helpful.