test-design-heuristics

name	test-design-heuristics
description	Use when deciding what to test for a change. Covers the test pyramid, risk-based prioritization, boundary and equivalence partitioning, the edge cases worth checking, and — just as important — what not to test.

Test design heuristics

The goal of a test is to catch a regression that matters, cheaply. Optimize for signal per test, not for a coverage number.

Pick the level (the pyramid)

• Unit — fast, many, isolated. Pure logic, branching, transformations. Most tests live here.
• Integration — fewer. Real boundaries: a DB, a queue, an HTTP client, the file system. Test the seam, not the whole world.
• End-to-end — fewest. One or two happy-path journeys that prove the pieces connect.

Push each behavior to the lowest level that can meaningfully exercise it.

Prioritize by risk

Test first where a bug would hurt most and is most likely: money, auth, data loss, irreversible actions, and the code that just changed. Don't spend the same effort on a log-formatting helper as on a payment path.

Find the cases

• Equivalence classes — one representative per class of input, not every value.
• Boundaries — 0, 1, n, n+1, max, just-over-max. Off-by-one lives here.
• Empty / null / missing — empty list, null field, absent config, zero-length string.
• Error paths — what happens when the dependency throws, times out, or returns garbage.
• Idempotency & concurrency — only when the code is retried or runs in parallel.

What NOT to test

• Framework or library internals — trust them; test your use of them.
• Trivial getters/setters and pass-through wrappers with no logic.
• The same logic at three levels — pick one level and assert it well.
• Implementation details that aren't part of the contract — they make refactors painful.

A test plan that says "this part needs no test, here's why" is more credible than one that tries to test everything.