Test coverage that earns its keep

Coverage is the most gamed metric in software. It is easy to measure, easy to raise, and only loosely connected to whether your tests would catch a real regression.

What high coverage does not tell you

A suite can execute 95% of lines and assert almost nothing meaningful. Tests that call a function and check it did not throw contribute to coverage and catch nothing.

The useful question is not "how much code ran" but "what would break the build". If you can delete an important `if` and the suite stays green, the number is decoration.

Where tests pay for themselves

• **Business rules with real consequences.** Pricing, permissions, tax, anything with money or access attached.
• **Error paths.** The half of the code that only runs on a bad day, and therefore only gets exercised on a bad day.
• **Bugs you have already fixed.** A regression test for every incident, always. Cheap to write, and it stops the same fault returning.
• **Boundaries.** Empty, one, many, maximum, null, malformed. This is where the defects actually live.

Where they usually do not

Framework glue, straightforward getters, and the specific arrangement of a UI that will be redesigned next quarter. Those tests cost more in maintenance friction than they return, and they train people to ignore red builds.

What changed recently

Writing thorough edge-case tests used to be the first thing cut under deadline pressure - not because anyone disagreed with them, but because the hours had to come from somewhere. Generating that tier of test is now cheap enough that it survives the conversation.

The judgement about *what deserves a test* has not been automated at all. That is still the part that requires knowing the system, and it is still the part that determines whether the suite is worth running.