This is NOT a test.
Test Driven Development is hot, just like unit testing your software and any other kinds of (automated) testing. And as we all know: sometimes stuff that's hot is misinterpreted, explained wrong or just simply used in a really bad way. Unfortunately, testing is no exception to this rule...
Not too long ago I had a discussion with a project manager who told me the code in his project had a code coverage close to 100%. Because of that, so he felt, his software would be darn close to perfect. I then asked him if testers had validated the unit tests his developers had made. The answer was no, but he didn't see the need for that because "the code coverage was so high". I'll spare you the details of the discussion, but let's say it led to a few new insights for at least one of us ;).
I'l try to make my point over here with some examples. Let's first make a very simple (trivial) method.
public static string LowercaseConcatenateStrings(string first, string second)
{
string result;
result = first.ToLower();
result += second.ToLower();
return result;
}
As you can see this is a simple method which converts both input parameters to lowercase and concatenates them. Now let's see a unittest which will result in 100% code coverage:
[TestMethod]
public void TestLowercaseConcatenate()
{
string result = UnitTestSample.LowercaseConcatenateStrings("test1", "test2");
Assert.IsNotNull(result, "Returnvalue is null!");
}
This unittest does result in 100% code coverage, but does not test all the scenario's applicable to the method. A null value for one of either parameters results in an unhandled exception. It doesn't even check if the value of the returned string is anything like it should be! These tests (and the code) are far from perfect, even though the coverage is 100%.
This is a simple example where it's easy to determine the flaws, but you can imagine a more complex method would require an expert's eye to ensure the quality of the asserts is up to par. A method of 20 lines with lots of calculations and object modifications, cannot be asserted with a check to see if the object merely exists.
Of course, and this should come as no surprise, testers are able to look at a piece of code or software a little bit different than developers do, so why not use their expertise. In short: check the quality of your assertions!