testing-strategy

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 transformations. No database, no network, no filesystem, no clock. If it needs a mock of something you own, that is usually a design signal: the logic wants to be extracted from its dependencies.

Integration — the things unit tests structurally cannot catch: does the query return what you think, does the migration apply, does the authorization middleware actually reject, does the transaction roll back, does the serialiser produce the right shape. Use a real database (a container, or a per-worker schema). A mocked database tests your mock.