If you're like me and you believe the tests serve as the documentation, I've noticed the following naming conventions help further this concept:
- Have a standard name for each test fixture. I usually append the word "Fixture" on each fixture so I know it is a fixture when looking at the file. I also prepend the name "Dummy" or "Mock" when creating a dummy or mock class, so that I can easily find whether such a class exists.
- Keep each test focused on a specific test-case. Don't cover numerous cases in one test because it seems easier or because there is less code; keep each test centered on a specific behavior of the class under test (CUT). This greatly helps readers of the tests understand what each test covers. By following this rule along with number three below, the tests really do serve as the documentation.
- Give each test a very descriptive name that explains what it does. If you're very descriptive you can then read the name and understand exactly what behavior the test covers.
- If your test covers the case of the CUT throwing an exception and you're using the ExpectedException attribute, include this in the test name. For instance, if the class you're testing is a Seat and it accepts a height argument in its constructor but throws a BusinessException if this argument is greater than 42, name the test something like ConstructorWithHeightGreaterThanFourtyTwoThrowsBusinessException. This is an extension of item number three above, but the reason I separated it is because one reason for including the fact that the test expects an exception is because--at the time of writing this--if you include your test suite(s) in your NCover analysis, NCover doesn't count any of the code in a test after the exception is thrown as being covered...even if the code consists solely of the end bracket of the test method. For instance, if I have a test method like this:
[Test]
[ExpectedException(typeof(Exception))]
public void ThrowException()
{
throw new Exception("Exception");
}
NCover will report the last '}' character as unvisited, therefore getting rid of 100% coverage. By telling readers your test expects an exception via the name of the test method, when analyzing the NCover output they will see it is at 99% and realize it will never reach 100% because it expects an exception...and consequently will save time by not looking into the code.
I like to include not only all the project's dlls in my NCover run but also the test suite(s). This is because I've been surprised in the past when NCover tells me that some of my tests don't run all their code. Perhaps my test expects an exception in the last line of the test, but the same exception type is actually thrown midway through the test method--which still leads to a green result. Once a week or so I take a look at the NCover output in regards to the test suite(s) and then check those that aren't 100% covered. If I see that a test declares it expects an exception and is 99% covered, I don't have to look at the NCover analysis via NCoverExplorer for that particular test and I can therefore save time. However, if it's at 66% or something similar I then know I need to take a closer look.