Test coverage
Why it matters
With good coverage on the parts that matter, a change that breaks something is more likely to turn a check red before a customer sees it. With none, every release is shipped on trust. That matters more when an AI coding agent is writing the code, because it can change many files at once and cannot be relied on to notice what it broke.
A perfect percentage is a trap of its own. Teams that chase it write tests to lift the figure, not to catch failures.
How to apply it
- Decide first where a failure would hurt most: payments, sign-in, permissions, data deletion, the core workflow. Cover those paths before anything else.
- Write tests that assert a specific correct value, not tests that only confirm the code did not crash.
- Add a test the moment a bug is fixed, so the same fault cannot return unseen.
- Watch the trend rather than a single figure, and read gaps as a map of where you are exposed.
- Run the tests automatically on every change through CI/CD, so nobody has to remember.
What it is
An automated test is a small program that runs part of your product and checks the result. Test coverage is a report that says how much of the code was actually run while the tests ran. If a product has 1,000 lines and the tests run 700 of them, line coverage is 70 per cent. Some tools also measure branches, which count whether both sides of each if-then decision were exercised.
The number tells you what was run. It does not tell you what was checked. A test that runs a function and never looks at its answer counts as coverage but protects nothing.
