What is code coverage and what does it miss?

Code coverage measures how much of your code actually ran while the test suite executed. Tools such as Jest, Vitest or Istanbul instrument the code and report it, usually broken into four numbers:

• Line — which lines executed.
• Statement — which statements executed (differs from lines when several sit on one line).
• Branch — whether both sides of each if, ternary and && were taken.
• Function — which functions were called at least once.

Branch coverage is the one worth watching. Line coverage can read 100% while half your conditions were never exercised:

function discount(price, isMember) {
  return isMember ? price * 0.9 : price;
}

test("applies member discount", () => {
  expect(discount(100, true)).toBe(90);
});
// 100% line coverage, 50% branch coverage — the non-member path is untested

What the number does not tell you

Coverage proves code ran, not that it was checked. A test with no assertion still counts:

test("does not crash", () => {
  discount(100, true);   // covered, verifies nothing
});

It also says nothing about missing test cases — empty arrays, null inputs, network failures — because code that does not exist cannot be measured.

Using it sensibly

Treat coverage as a way to find untested areas, not as a target to hit. Chasing 100% pushes people to write assertion-free tests for trivial getters while the complex logic stays weakly tested. A practical approach is to set a floor (say 70–80%) to stop regressions, then read the uncovered-lines report and ask whether each gap matters.