If the expected result of the method being tested exists in the official documentation of the method, then indicating the expected result in the test names would be redundant. In fact, if the purpose is to document the method, then the documentation should be written in the method's XML documentation which would provide Intellisense info and more.
Why must anything besides the method being tested really be included in a test name?
It's a matter of convention and development practice. If you're implementing using TDD, documenting the expected result in the test name keeps you focused on your goal. There is also no XML docs to specify the expected result on as you haven't implemented the class yet. (You're writing the test first.) The additional benefit here is that documenting the expected result in the test means that you can execute the specification (aka test) and verify that it is correct. You can't execute XML docs. :) (You do have to make sure that test name and test code match though. This is easier than making sure test code and XML docs in another file match.)
Beyond that, there are tools that will extract class/method names and generate specification documents for you in HTML. This allows you to easily generate reports that can be reviewed by all stakeholders. You would want to do this for high-level tests/specs, such as "When a 10 percent single-item discount code is applied during checkout, the most expensive item in the shopping cart is discounted by 10 percent." This allows stakeholders to verify (because the specs are executing/passing) that the system implements certain business-relevant features.
Well it doesn't, but if you say have 10+ tests trying different scenarios against the same method, not having it as descriptive as possible gets to be a real hassle when looking at them.
In the test list editor, you get the name of the test and that's all. On my project we currently have 600+ tests, so knowing which method does what can be really important when you are running them, and you want to try a certain scenario.
I don't know and I don't like the most common naming conventions. I find them hard to read and understand. Based on few other naming conventions (which I cannot tell which one now) I developed my own, here it is:
Let's say I have the following class to test:
public class ColorParser {
public static bool TryParseHex(string value, out Color color) {
// Code to parse the hex color value.
}
}
My unit tests for this particular method look like the following:
public class ColorParserTests
{
public class TryParseHexTests
{
[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void TestNullValue()
{
Color color = Color.Empty;
ColorParser.TryParseHex(null, out color);
}
[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void TestEmptyValue()
{
Color color = Color.Empty;
ColorParser.TryParseHex(string.Empty, out color);
}
[TestMethod]
public void TestInvalidValues()
{
string[] invalidValues = new string[]
{
"#",
"FF",
"#FF",
"#FFAA",
"asdf"
};
foreach (var invalidValue in invalidValues)
{
Color color = Color.Empty;
bool result = ColorParser.TryParseHex(invalidValue, out color);
Assert.IsFalse(result, string.Format("Value '{0}' must not pass the test!", invalidValue));
}
}
[TestMethod]
public void TestValidValues()
{
// Spaces are intended and a part of the test!
Dictionary<string, Color> validValues = new Dictionary<string, Color>()
{
{" #000000", Color.FromArgb(0,0,0)},
{" #010203 ", Color.FromArgb(1,2,3)},
{"#00FFFF", Color.FromArgb(0,255,255)},
{"#FF00FFFF", Color.FromArgb(255,0,255,255)},
};
foreach (var validValue in validValues)
{
Color color = Color.Empty;
bool result = ColorParser.TryParseHex(validValue.Key, out color);
Assert.IsTrue(result, string.Format("Value '{0}' must pass the test!", validValue.Key));
Assert.AreEqual(validValue.Value, color, "Parsed color must be the same.");
}
}
}
}
The idea behind this is that the particualr tests are groupped (in classes) which allows me to test them separately. There is no need to repeat the method name being tested each time. The test method begins with a verb like a method name should and and it just contains a short information about what exacly is being tested. Everything else is inside the test.
This way I very quickly know what I'm testing and the results should be defined inside the tests themselves beacause what I'm testing is the behaviour for some values that either are correct or incorrect.
Nulls and Emptys and other special cases that throw exceptions deserve they own tests.
You could broke the tests up and write more tests like TestValuesWithSpaces or TestNegativeDeposit or TestUserNameWithInvalidCharacters etc. It always depends how much to test there is and how precise you want to do it. In this case I thought it's sufficient. Anyway I think this is very descriptive.
I always thought if something doesnt suit ur needs dont use it/mend it to fit your needs. The only logical explanation i can think of is that after you run the test methods you can export the pass/fail record and give it to the managers so that they can have a smile on their face cuz I dont know why they are so serious :).. Jokes apart.. another reason why BDD is slowly but surely gaining momentum.
Really you can name your test methods whatever you want, they're just methods. Pick a naming convention that works for you/your team.
However, most test runners do not display the XML documentation, only the method name. If the method name is sufficiently descriptive, you do not need to examine the test code to get an idea of what happened (or didn't happen) to cause the test to fail.
The test name should include the method being tested and the variant being tested. Typically you should have a lot more tests than methods being tested. You want at least a test for all boundary conditions, different branches, etc.
MyMethod_Zero()
MyMethod_MinValue()
MyMethod_MaxValue()
MyMethod_SomeBranchTest()
etc.
Because PoppingEmptyStackThrowsInvalidOperationException() is far easier to understand when looking at a test runner than StackPopTest_1()
