Should code coverage be used as a "Milestone" that can block a project's progression?

Question

I am a development manager on a project with a painfully low unit test code coverage and we are definately feeling the weight of the "techincal debt" in the legacy code in our system.

My question is if anyone uses code coverage as a milestone or development threshold that prevents the project from moving to the next sprint until the code coverage reaches a specific level? What is the "best practice" for using the code coverage metric?

Answer 1

Code coverage is a very relative thing. First of all because code coverage alone tells you nothing about the quality of your code or your unit tests. Secondly, sometimes it's easy to get 90% coverage with only a few tests, but sometimes it's very hard to even get to 50%. This is especially true with legacy projects which very often aren't designed to aid unit testing (to avoid external dependencies for example).

If you really want to use it as a milestone my advice is to take some important classes of your code, for example those who hold a lot of business logic, and see whether it's easy to achieve a high code coverage % on it. If this is the case, be sure the code coverage of such classes always stays up to par.

My experience tells me it takes up a lot of time to get high code coverage on legacy classes, and this isn't always worth the investment.

I hope this helps!