Test Coverage
- In Turkish
- Test Kapsamı
In short
Test coverage is a metric that measures how much of a program's source code is executed when its automated tests run, usually shown as a percentage.
What is test coverage?
Test coverage, often called code coverage, tells you which parts of your code ran during the test suite and which parts did not. A coverage tool reports a percentage, such as 82%, and usually highlights uncovered lines so you can spot the gaps at a glance.
Coverage tools instrument the code, meaning they add hidden counters that record every line, branch, and function that executes while the tests run. Line coverage counts executed lines, branch coverage checks whether both sides of each if were taken, and function coverage counts functions that were called at least once. Branch coverage is stricter than line coverage and often reveals untested edge cases.
Think of coverage as a map of the rooms a security guard walked through: it shows where they went, not whether they looked carefully. Teams show coverage reports in pull requests and CI/CD pipelines, and some fail the build if coverage drops below a threshold such as 80%.
A common misconception is that high coverage means well-tested code. Coverage only proves that code ran, not that the tests checked the right results, and a test with no assertions can still reach 100%. Use coverage to find untested areas, not as a goal in itself.
Key takeaways
- Coverage shows which code ran during tests, usually as a percentage.
- Common types are line, branch, and function coverage.
- Branch coverage is stricter and catches untested conditions.
- High coverage does not guarantee good tests or bug-free code.
Example
function discount(price, isMember) {
let total = price;
if (isMember) total = price * 0.9;
return total;
}
// Test 1 runs every line above: 100% line coverage.
assert.equal(discount(100, true), 90);
// But the "not a member" branch never ran: only 50% branch coverage.
// Test 2 covers it and brings branch coverage to 100%.
assert.equal(discount(100, false), 100);Readers ask
What is a good test coverage percentage?
Many teams aim for roughly 70 to 90 percent, but there is no universal number. Covering critical business logic thoroughly matters more than hitting a specific figure, and chasing 100 percent often leads to low-value tests.
Is code coverage the same as test coverage?
In everyday use, yes: both usually mean the percentage of code executed by tests. Some people use test coverage more broadly to mean how many requirements or features are tested, not just lines of code.
See also
- Unit TestTesting & Quality, p. 35A unit test is a small, automated check that verifies one function, method, or class behaves correctly in isolation from the rest of the program.
- Test-Driven DevelopmentTesting & Quality, p. 34Test-driven development is a coding practice in which you write a failing test first, then write just enough code to pass it, and then clean up the design.
- Regression TestingTesting & Quality, p. 22Regression testing is the practice of re-running existing tests after a code change to make sure that features which used to work have not broken.
- CI/CDDevOps & Cloud, p. 9CI/CD is a set of automated practices that build, test, and release code changes frequently, so software can be delivered to users quickly and safely.
- Code ReviewVersion Control, p. 4A code review is the practice of having other developers check code changes before they are merged, to catch bugs, improve quality, and share knowledge.
- White-Box TestingTesting & Quality, p. 36White-box testing designs tests from knowledge of the code's internal structure, so that its statements, branches and paths are exercised and checked directly.
Spotted a mistake or something missing on this page?Suggest an edit