# The Problem With Code Coverage Metrics

DevFeed: [The Problem With Code Coverage Metrics](<https://devfeed.tech/articles/the-problem-with-code-coverage-metrics-24933.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/04/16/do-not-misuse-code-coverage/>)

Author: umer

Published: 2016-04-16T00:00:00Z

Content type: opinion

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [test-coverage](<https://devfeed.tech/topics/test-coverage.md>), [Test coverage](<https://devfeed.tech/topics/coverage.md>), [Code quality](<https://devfeed.tech/topics/code-quality.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Development](<https://devfeed.tech/topics/development.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [code-coverage](<https://devfeed.tech/tags/code-coverage.md>), [code-quality](<https://devfeed.tech/tags/code-quality.md>), [developers](<https://devfeed.tech/tags/developers.md>), [development](<https://devfeed.tech/tags/development.md>), [quality](<https://devfeed.tech/tags/quality.md>), [testing](<https://devfeed.tech/tags/testing.md>), [tests](<https://devfeed.tech/tags/tests.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

The article argues that code coverage is useful for identifying untested code but is a poor standalone measure of code or test quality. Treating a coverage percentage as a management goal can encourage brittle, meaningless tests and distract teams from thoughtful test design.

## Source excerpt

Code coverage is a valuable metric. Software developers write tests for the code they have written and run code coverage analysis which gives them an assessment of how much of their code is covered by tests or more importantly what parts of the code are untested. Some organizations and managers make high level of code coverage mandatory for their teams. "90% code coverage and no less!", says the manager. It becomes another metric in management's arsenal to assess code quality and (god forbid) team's performance. It's a big mistake to interpret and use code coverage in this way. Code coverage doesn't say anything about the quality of the code or the tests. It is very easy to get high code coverage with low quality testing. Code coverage number will not say that some parameter was not checked for null value, that the contract required Strings to be trim()ed before use or that even though all lines of code were hit, some particular sequence wasn't tested. Nope. The tests might be meaningless and brittle masking real issues, but who cares, as long as there is coverage. Let me get this straight again: code coverage is a valuable metric. But when management turns it into a goal and becomes fixated on it to measure quality and performance, things rapidly disintegrate. It might have to do with our psychology or our nature, but we humans optimize our performance according to how we are being measured and become distracted from what really matters. Testing requires thoughtfulness and careful design. Scott Bain, author at Sustainable Test Driven Development explained it better: If developers are writing unit tests because "the boss says so" then they have no real professional or personal motivation driving the activity. They're doing it because they have to, not because they want to. Thus, they will put in whatever effort they have to in order to increase their code coverage to the required level and not one bit more. It becomes a "tedious thing I have to do to before I can ch