TDD and a code coverage tools

Arguments about how important is the use of code coverage tools are not scarce. I don't want to participate in any of those. I merely want to show that using a coverage tool while doing TDD will increase the probability of not leaving stones unturned.

The generally recommended way to do TDD looks like something along these lines:

1 - write a failing test case
2 - write the simplest code modifications that will make the test pass
3 - we are done if can't think of more test cases to write
4 - go back to (1)

If we absolutely stick to the recommended way, chances are that our test cases cover the totality of the code we write to make them pass. Unfortunately I would adventure to say that somehow in step 2 we tend to write more code that we should, and as a result we end up with code that is not tested.

Ending up with code that is not tested is precisely one of the things TDD tries to make sure we avoid.

Good thing is that with the help of a code coverage tool it is very easy to make sure we don't have code that is not tested. All we have to do is modify step 3 to look like:

3 - we are done if can't think of more test cases to write, and the code coverage of the class we are actually writing is 100% when all the test for that class are run.

---
EclEmma, a Java Code Coverage Plugin For Eclipse