Test-Driven Development & Code Coverage

On an internal email discussion, someone asked for some help applying Code Coverage tools to evaluate their Unit Tests.  So, I blog:

Is it really important to you to get Code Coverage on your TDD’d code?


From http://c2.com/cgi/wiki?UnitTest:


Are we testing too much? The purpose of unit testing is to increase developer mobility. It is not to verify the correctness of your program. Are you testing privates? Are you testing simple accessors? Are you trying to make unit tests perform 100% code coverage? These are all practices that may have some value, but also may serve to defeat the real purpose of unit tests.


When I’m doing TDD, I would look at Code Coverage as a way of measuring my TDD skills, not of my unit test quality.  That is, I would look at the <100% results & try to under why I missed them, to see if I can learn something that would make me better at TDD. 


There is no rule that TDD must generate 100% coverage, and there is no guarantee that 100% coverage means that you’ve succeeded with TDD.


The main way I measure the quality of my Unit Tests is:

Comments (3)

  1. Darren Oakey says:

    I thought this was interesting – I actually use code coverage for a VERY different reason. I use it to speed up development.

    What you say? Well – I do think we TDD people can get bogged down in writing tests. I take the pragmatic middle ground between doing everything test first, and writing tests later.

    I write one or two tests of what I’m doing – enough to show me the structure I’m aiming for. I then code it. I then run coverage checks, and add tests until I’m up to 100. 100 isn’t all that hard to hit – you have common patterns to take care of some things, and other things that are harder, like error conditions, are actually quite worth the effort anyway..

    This gives me a fairly comprehensive suite of tests. It gives me CONFIDENCE not that the code is doing what it should, but at least that IT’S NOT GOING TO BREAK OR BE BROKEN. (which is a good start :))

    So – for me the coverage testing tool saves me heaps of time because I don’t have to "think" about what I should be testing, I rush out a test, rush out some code, rush out some more tests, and can do it all without engaging a neuron!

  2. Mike Woodhouse says:

    Really important? I wouldn’t think so. Useful? Sure, in the same way that all tools can be useful.

    I would consider myself to be but a novice in TDD terms (plenty of theory, not enough practice yet) and I do feel at present that a code coverage tool might help me to check that my tests are really driving my code. I don’t necessarily expect 100% coverage but I’d like to know that any code not covered is by intent rather than accident.

  3. I like what Mike says.

    I am very much looking forward to having code coverage in Team System, not so that I can be sure I have 100% coverage, but to validate that I have not missed something.

    Alright, I am anal enough that I probably would aim for 100% coverage too.

    Despite having used NUnit since 2.0 was released, the recent discussions of only testing public API is causing me to rethink a bit. If I do only public API tests, I think I will want code coverage even more. Time will tell