The actual test is important, but if a test fails and it's hard to figure out what to do to fix the code to pass the test or where the problem is, developers can waste precious time tracking down where the roots of failures are. The name of a test, its parent class, and (to a certain extent) the namespace and project name can go a long way to providing useful context in failure messages or automated testing reports. Let's take the following class, for example:
namespace UnitTests
{
[TestClass]
public class Class1Tests
{
[TestMethod]
public void TestMethod1()
{
var o = new Class1();
var actual = o.Method1();
Assert.AreEqual(42, actual);
}
}
}
If the TestMethod1 test failed in its assertion, we would see the following screenshot in the Test Results report:
This report really doesn't tell us much. We know that TestMethod1 had an assertion failed and that it expected 43 but got 42. But, had I never worked on this method and I made a code change that caused this, how likely would this...