Coverage is the wrong target
Chasing a coverage percentage produces tests of trivial code and leaves the complicated parts untested, because they are harder to write tests for.
The useful question is not how much is tested but whether you could change the code confidently.
What to test first
- Calculations — pricing, tax, commission, anything with arithmetic
- Money paths — payment, refunds, invoicing
- Authorisation — who can see and do what
- Integrations — what happens when the other system fails
- Anything that has broken before
The last one is the most useful heuristic. A bug that has occurred once will occur again unless a test prevents it.
Different tests for different jobs
| Type | Use for |
|---|---|
| Unit tests | Calculations and business rules |
| Integration tests | Database interactions and queries |
| Feature tests | Complete user journeys |
| Contract tests | External API expectations |
A small number of feature tests covering the main journeys catches more real problems than a large number of unit tests on trivial methods.
Make them run automatically
Tests that require someone to remember to run them stop being run within a month. They should run on every push, automatically, with a visible result.
That is a day of setup and it is what turns a test suite from a nice idea into a working safety net.
Testing legacy code
- Start with characterisation tests — capture current behaviour
- Test at the highest level you can, since units may be untestable
- Add tests when you touch a piece of code, not as a separate project
- Accept partial coverage; it is better than none