As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

7 Answers
7

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! :)

Slight contradiction "so long as it is readable, and clear" and "who... cares". Well everyone cares when it isn't readable & clear, so that's why it matters. :-)
– David VictorMay 31 '12 at 11:41

1

One additional argument for prefix. When you are searching for a file in IDE, you can easily search test cases by starting off with Test and your class name. If the class name and the test class name is same, we are going to always have to pause and read the path of two files
– THIS USER NEEDS HELPJan 12 '18 at 0:26

@THISUSERNEEDSHELP I think your point can be easily overcome by having a good folder structure like src/libs & src/tests . I know the some test runner frameworks do require a prefix like test for test code identification, so in those cases won't be avoided, but for the rest it can be a repetitive no required prefix.
– negrotico19Jan 30 at 17:45

@negrotico19 I am thinking of the case like in IntelliJ when you Search Everywhere (shift shift) or Find a Class By Name (CMD O). I get that it will be differentiated by either folder structure or module structure, but when we search for something, we already know what we want to search for. For example, if I am looking for a test, I want to limit my search to test and then search for the name, rather than searching the name and then filter out test manually by eyes. It's a small distinction, but it's much easier to "test [class name]" and have only one pop up and reduce mental load
– THIS USER NEEDS HELPJan 31 at 18:49

Well for one thing, it’s a nice way to keep tests organized. All the
tests (or facts) for a method are grouped together. For example, if
you use the CTRL+M, CTRL+O shortcut to collapse method bodies, you can
easily scan your tests and read them like a spec for your code.

I tend to use the convention of MethodName_DoesWhat_WhenTheseConditions so for example:

Sum_ThrowsException_WhenNegativeNumberAs1stParam

However, what I do see a lot is to make the test name follow the unit testing structure of

Arrange

Act

Assert

Which also follows the BDD / Gherkin syntax of:

Given

When

Then

which would be to name the test in the manner of: UnderTheseTestConditions_WhenIDoThis_ThenIGetThis

so to your example:

WhenNegativeNumberAs1stParam_Sum_ThrowsAnException

However I do much prefer putting the method name being tested first, because then the tests can be arranged alphabetically, or appear alphabetically sorted in the member dropdown box in VisStudio, and all the tests for 1 method are grouped together.

In any case, I like separating the major sections of the test name with underscores, as opposed to every word, because I think it makes it easier to read and get the point of the test across.

In other words, I like: Sum_ThrowsException_WhenNegativeNumberAs1stParam better than Sum_Throws_Exception_When_Negative_Number_As_1st_Param.

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

+1 for link to my post -- though it's unnecessary to use a "Test" prefix in your Tests. Be sure that your tests specify the expected behavior. For example, CanRetrieveProperCountWhenAddingMultipleItems()
– bryanbcookSep 2 '09 at 14:55

2

I don't like it because it does Not include the expected behaviour
– Johannes RudolphSep 3 '09 at 9:25

@metro-smurf: interesting distinction, I've never heard the term PascalCase used, and I've been doing this for a long time. I only see the term PascalCase come up in Microsoft developer circles, is that what you do?
– Frank SzczerbaJun 19 '09 at 19:02

History around Pascal Casing and Camel Casing (from: Brad Abrams - blogs.msdn.com/brada/archive/2004/02/03/67024.aspx )... "In the initial design of the Framework we had hundreds of hours of debate about naming style. To facilitate these debates we coined a number of terms. With Anders Heilsberg (the original designer of Turbo Pascal) a key member of the design team, it is no wonder that we chose the term Pascal Casing for the casing style popularized by the Pascal programming language."
– HeliacFeb 5 '13 at 13:13

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

Interesting approach. Some people may argue that the T prefix conflicts with convention you use in generics (e.g. func(T1, T2, TResult)), but I personally don't care as long as there's a consensus within the team. The names are short which makes things more readable too.
– stungJan 10 '11 at 22:00

I agree, Hungarian notation has been depricated and because the conflict with standard generic type parameters, I don't see an exception applying in this case (like there is for interfaces).
– SonOfPirateDec 13 '11 at 13:19