The Deceiving Personality of Test Coverage

Running Ncover, or Emma, or things like that give you some idea of what your code coverage is like, but what does it all really mean?

We should always keep in mind that such ideas of “coverage” really only indicate what lines in our code has been touched by our tests, and really doesn’t tell us anything about what functionality we’re testing.

Not that there are any arrogant programmers in this world, but if there were, a test coverage percentage of 84% might lead one to believe that their heads are bigger than they really are. This does not mean that your system is inpenetrable by any means.

Hey look, we’re back to the benefits of test driven development…

Test driven development, when done correctly, assures you that you have a test for every piece of functionality you add into a system. It also helps you focus on one thing at a time.

Check out this test:

public void testIsValidWhenDogIsBrown() {
// setup
Dog dog = new Dog();
dog.color = "Brown";
 
// execute
bool isValid = dog.isValid();
 
// verify
assertTrue(isValid);
}

Minimal effort to make the test pass:

public class Dog {
bool isValid() {
return true;
}
}

This forces you to have a negative test.

public void testIsNotValidWhenDogIsBrown() {
// setup
Dog dog = new Dog();
dog.color = "Red";
 
// execute
bool isValid = dog.isValid();
 
// verify
assertTrue(isValid);
}

The natural thing to do would just be to write the first test, and miss the second.

Yay test driven development… I’m not going to reinvent the wheel, or try to convince anyone that it’s the right way to go, but I am not comfortable coding without having a test first, not only for a refactoring safety net, but also to ensure that I am implementing everything I need, and only everything I need.