mediumConceptEntryMidSenior
Your team reports 90 per cent line coverage. What does that number tell you, and what does it not?
4 min readUpdated 2026-08-15Target archetype: Big Tech, Enterprise Captive, Product Startup
Answer
Short answer
Line coverage tells you which lines executed while the tests ran, which is not the same as which behaviours were verified: a test with no assertions still counts, and the interesting information is in the uncovered lines and in whether the tests would fail if the code were wrong.
Was this answer helpful?
Likely follow-ups
- What would you measure instead if you wanted to know whether the tests would catch a bug?
- A file sits at 100 per cent and still ships a defect. Give me a way that happens.
- Would you block a merge when coverage falls? What goes wrong with that rule?
- Which parts of a codebase do you deliberately not care about the coverage of?
Related questions
- A test fails in CI and all you get is 'expected true, got false'. What should the framework have given you instead?mediumAlso on assertions4 min
- A flex item with a long URL in it pushes past its container instead of shrinking. Why does flex-shrink not save you?mediumSame kind of round: concept4 min
- A third-party script in the head delays your first paint by a second. What do async, defer and type="module" each change about parsing and execution order?mediumSame kind of round: concept5 min
- You need a random number from 1 to 6 and you wrote rand() % 6. What is wrong with that, and when does it stop being merely wrong and become a vulnerability?mediumSame kind of round: concept4 min