Code Coverage

I've long been a fan of unit tests; they just make sense, and there's really no argument for not having them on production-ready code other than sheer laziness and not giving a crap about quality in general.

Code coverage appears to be a different issue though.

My stance, before I go on, is that I like to get as much code coverage as possible from my unit tests. A full 100% is just not possible these days as I tend to reduce boilerplate code by using Lombok, but I still strive for the most I can get.

Now I've worked with some very talented guys over the years, and one guy in particular is someone who I admire for his sheer level of technical ability. However, he would question my zest for code coverage, asking that just because the code coverage tools showed that a unit test had run through some code, how could you be sure that that piece of  code was actually tested, and not just executed for the sake of code coverage?

And he had a very valid point. And not only that, it was a point that I had difficulty providing any kind of logical answer to that didn't make me come across as sounding like I had OCD or something. Then I started working on a side-project called Iterations, and it was here that I finally found the answer.

With no time constraints on the project, and with no deadlines to hit, I was free to take my time to unit test everything and maintain the highest level of code coverage possible.  And here's what I found:

Increasing code coverage forces more unit tests to be written. Writing more unit tests helps enforce a cleaner design.

As I was working on Iterations, I would find that if unit-testing a piece of code proved to be a pain, then there was something fundamentally wrong with the design of that particular component.  Either a class was becoming too large, or starting to do too much, or inheritance was beginning to make things difficult, or whatever...the key point was that I obviously needed to re-think things, and refactor.

And so I would refactor the design to make the tests much simpler and easier to implement. Lather, rinse, and repeat enough times, and you end up with one heck of a clean design.

So to answer his question, he is absolutely right in that increasing code coverage does not necessarily ensure that the code is really being tested. But the real benefits lie in the overall increase in the quality of the underlying design itself, and that is something that is most definitely something a developer should always strive for.