Learn the vocabulary of measuring which lines and branches actually execute during a test suite run.
0 / 5 completed
1 / 5
At standup, a dev mentions a metric that reports the percentage of a codebase's lines, branches, or statements that were actually executed while running the test suite. What is this metric called?
Code coverage is exactly this: code coverage is a metric that reports the percentage of a codebase's lines, branches, or statements that were actually executed while running the test suite, giving a quantitative sense of how much of the code was exercised. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This measure-what-actually-ran approach is exactly why code coverage can flag entire files or branches that no test ever touches.
2 / 5
During a design review, the team tracks branch coverage rather than just line coverage, specifically because reporting whether both the true and false paths of every conditional were exercised catches untested branches that line coverage alone would miss. Which capability does this provide?
Branch coverage here provides visibility into untested conditional paths, since it reports whether both the true and false outcomes of every conditional were exercised, while line coverage alone can mark a line covered even if only one of its branches ever actually ran during the test suite. Line coverage alone gives no signal about which specific path through a conditional was tested. This both-paths-tracked behavior is exactly why branch coverage catches untested edge cases that line coverage reports as fully covered.
3 / 5
In a code review, a dev notices a critical conditional's error-handling branch has never once been exercised by the test suite, yet the team's coverage report shows the surrounding function at 100% line coverage. What does this represent?
This is a missed opportunity to track branch coverage, since reporting whether both outcomes of the conditional were exercised would reveal the untested error-handling branch that line coverage alone is hiding. A cache eviction policy is an unrelated concept about discarded cache entries. This 100%-line-coverage-hides-an-untested-branch pattern is exactly the kind of false confidence a reviewer flags once error-handling paths matter for reliability.
4 / 5
An incident report shows a critical error-handling branch crashed in production the first time it ever actually ran, because the team's coverage report showed the surrounding function at 100% line coverage and nobody realized that branch had never been exercised by a test. What practice would prevent this?
Tracking branch coverage flags an untested conditional path instead of letting it hide behind a misleadingly high line-coverage percentage. Continuing to rely on line coverage alone regardless of how many untested branches it fails to reveal is exactly what caused the crash described in this incident. This branch-coverage practice is the standard fix once line coverage alone is confirmed to hide untested paths.
5 / 5
During a PR review, a teammate asks why the team treats a high code-coverage percentage as necessary but not sufficient proof of test quality, instead of assuming 100% coverage means the code is fully tested. What is the reasoning?
Code coverage only reports that a line or branch executed during a test, not whether the test actually asserted the correct behavior, so a line can be 100% covered by a test with no meaningful assertions at all and still hide a real bug. This is exactly why a high coverage percentage is treated as a necessary baseline signal rather than sufficient proof that the tests actually verify correct behavior.
What does the "Code Coverage Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to code coverage vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — browse the full vocabulary exercises hub to find related modules covering adjacent IT topics and roles.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.