testing-strategylisted

# Testing Strategy A test suite has one job: **tell you, quickly and truthfully, whether the system still does what it is supposed to do.** Judge every testing decision against that. Coverage percentage, test count and framework choice are proxies, and proxies get gamed. --- ## The pyramid, and why it is that shape ``` ╱──────────╲ E2E few, slow, high confidence ╱ 5-10% ╲ the critical journeys only ╱──────────────╲ ╱ Integration ╲ 20-30% real database, real HTTP layer ╱──────────────────╲ where most real bugs live ╱────────────────────╲ ╱ Unit ╲ 60-70% milliseconds, no I/O ╱────────────────────���───╲ business rules and edge cases ``` The shape follows from cost. A unit test runs in a millisecond and fails precisely; an E2E test takes 30 seconds, is flakier, and tells you only that *something* broke. You want as much signal as possible from the cheap layer, and just enough from the expensive one to know the pieces are actually connected. **Both inversions are failures.** An ice-cream cone (mostly E2E) is slow and flaky, and people stop running it. A suite with no top has never tested that the parts work together — which is where integration bugs live by definition. --- ## What belongs at each layer **Unit** — business rules, calculations, state machines, validation, edge cases, error paths, pure transform