test-designlisted

# Test design A test suite has one job: **tell you the change you just made is safe**. Tests that fail for reasons unrelated to correctness, or pass while the system is broken, are worse than no tests — they cost time and teach the team to ignore red. ## What deserves a test Test what would be **expensive to get wrong** and **cheap to verify**: - Business rules and their edge cases — the discount tiers, the state machine. - Anything with a boundary: empty, one, many, max, past-max, negative, null. - Bugs you fixed. A regression test is the cheapest test you will ever write, because the failing case is already in your hand. - Contracts other code depends on: the shape of a public API, an event payload. Do **not** test: - Language and framework behaviour. You are not testing that the ORM saves rows. - Getters, setters, and pure delegation with no logic. - Implementation details — private helpers, call counts, internal ordering. These tests break on every refactor while catching nothing. - Mocks verifying other mocks. If the assertion only touches doubles, the test proves nothing about the system. **Coverage is a signal, not a target.** Low coverage on a payment module is information. 100% enforced by CI produces tests written to touch lines, which are the exact tests that pass while the code is wrong. Look at *what* is uncovered. ## Pick the level deliberately | Level | Use for | Cost | | --- | --- | --- | | Unit | Logic with branches: calculations, validation, s