What to Test (and What Not To)
A risk-based way to decide where tests pay off — and where they just slow you down.
More tests is not the goal. Confidence per unit of effort is. The job is to spend your testing budget where a bug would hurt the most and where a test is cheapest to keep green.
Start from risk, not from coverage
Coverage tells you what code ran during tests, not whether the important behaviour is protected. Ask two questions about each piece of behaviour: how likely is it to break, and how bad is it if it does? Anything that scores high on both deserves a test first.
- High value, high risk: money math, auth, data integrity, anything irreversible. Test thoroughly.
- High value, low risk: stable core flows. Cover with a few high-level tests.
- Low value, high churn: cosmetic UI, copy. Lean on types and a smoke test.
- Low value, low risk: getters, framework wiring. Usually skip.
Test behaviour, not implementation
A good test describes what the code should do from the outside. If renaming a private method or refactoring internals breaks the test even though behaviour is unchanged, the test was coupled to implementation — it will cost you on every refactor.
// ❌ Couples to implementation detail
expect(cart._items.length).toBe(2);
// ✅ Asserts observable behaviour
expect(cart.total()).toBe(42.0);
expect(cart.itemCount()).toBe(2);Tip: A quick heuristic: would a competent rewrite of this module, with the same public contract, still pass this test? If not, you are testing the implementation.
What usually is not worth testing
- Third-party library internals — trust their test suite, test your usage of them.
- Trivial pass-through code with no branching or logic.
- Generated code and type-only declarations.
- Exact pixel layout — prefer visual-regression snapshots over brittle assertions.
Then practise the inverse skill — writing the minimum test that drives a change — in the TDD playground, where the Red-Green-Refactor loop forces you to test one behaviour at a time.