Setting up and maintaining code coverage information for your unit tests adds huge drag to the development process. The overhead is on top of the the writing and maintaining unit tests themselves. The claim "code coverage improves product quality"" is tenuous at best, thus most of the projects do NOT collect any code coverage information, often guessing where and when to write more unit tests.
To start using code coverage you need to solve two problems:
- Make code coverage collection simple and turned on by default. It is very easy to do, see istanbul, my QUnit nodejs runner gt, or Karma
- Get more out of your code coverage information. I call this "High MPG Code Coverage".
Things I get from code coverage:
- I minimize number of tests I need to write because the coverage information signals when things are tested. As soon as I hit the lines, I am done. The best picture to visualize the coverage's role is a zipper: it keeps production code and test code in one to one relationship
- I can show the technical debt in the code using my risk-map chart. The larger rectangles correspond to more complex files (measured by static complexity tools), and the brighter shade of red corresponds to lower test code coverage. I can communicate the risk level of the project to the rest of the team.
- I can speed up tests using a tool like my untested, that keeps the current mapping between source and test files. Whenever I try to commit changed code, untested makes running just tests that cover the changed portion trivial. Even if all my tests executed together take hours, the pre-commit subset takes seconds, because it is highly targeted.
Get more out of your code coverage tool, and its setup will no longer seem like expensive overhead, but as the best time investment in your project's success.
Related: High MPG Unit Tests, presentation code coverage and tests