Is Code Coverage Important?

How much code coverage is enough? Do you consider having 100% code coverage an uphill task? Based on whom you talk to, the reply you get varies considerably. I have worked with Managers who would not compromise on anything less than 100% code coverage.  On the other hand, I have had the chance to work with clients who had about 30% or even less code coverage and relied heavily on their testers and QA, and had successful releases month after month.

In my opinion, code coverage data gives us an important insight on how effective our tests are, what parts of our source code are thoroughly executed. You can also look at the code coverage report and find out specific areas of code which are not exercised by our tests.

If you are following TDD, than I assume you must and will be having 100% coverage. The test early principle helps you in detecting and fixing bugs early in the life cycle of your project.

However, if you are working with legacy code, it is a herculean task to achieve 100% code coverage. I suggest that you start by taking baby steps. When I started working with one of my clients, they had 10% code coverage. The technical lead decided that it was humanely impossible to achieve 100% coverage with their several hundred thousands of lines of code. So, we decided to run metrics and code coverage on changes the developer made on a daily basis. We were able to fail the build when the coverage or quality went down for just those files which were checked in by the developer. We were able to easily convince the developers to maintain the quality and also write tests for the specific functionality they were implementing.

I remember reading an interview with Rod Jonhson here at Javalobby where Rod says:

Sugrue: When you talk about quality,  I presume as followers of best practice that you do a lot of test-driven development and a lot of unit testing. But, do you worry about coverage statistics. What is your opinion on code coverage with unit tests?

Johnson: We do. Pretty much all development in Spring projects is test-driven. And I think that something has been extremely helpful in terms of getting the good quality that we have achieved. We do worry about coverage, so we definitely track coverage across all of our projects.

We are not kind of the Taliban of test coverage, in that we don't have people writing pointless code so they can get from 97% to 99%, but we do really care about coverage and we like to try to ensure that the coverage gradually increases across all of our projects.

Actually, I have had some interesting discussions with Peter Cooper Ellis. Peter is really surprised at just how few bugs that we have in Spring. And I think, that is an example of how our embrace of test-driven development definitely gives us an advantage versus many traditional software vendors.
 

 If you want your project to be as successful as Spring, than you know what % of coverage you need. Let's all strive to "Aim for the highest".

Code coverage reports should be used on a daily basis to:

    * see what percentage of tests actually test our code
    * communicate with your testers and the QA team about the code bases which have very low test coverage
    * improve the coverage by writing additional tests as more functionality is added.

 What is the % you strive to achieve in your project? Is there a specific person designated to look at these reports? Do you break the build when the coverage drops? Do you have 100% coverage?

Share your thoughts and code coverage tips and tricks?