The test pyramid — why it exists and when to break it

This shape isn't an arbitrary convention — it falls directly out of the trade-offs the previous lessons already covered individually. Unit tests are fast and precise but structurally blind to wiring bugs; integration tests catch wiring bugs but are slower and less precise about the failure; E2E tests catch everything but are the slowest and most expensive to maintain. Given those three trade-offs, the rational allocation is: lean heavily on the cheap, fast, precise layer for the bulk of the coverage, use the next layer for the specific class of bug only it catches, and reserve the slowest, most expensive layer for a small number of the highest-value flows. The pyramid is that allocation, drawn as a picture.

There's no universal rule that says "70% unit, 20% integration, 10% E2E" — those specific numbers, when quoted, are a rough illustration of the shape (fewer as you go up), not a target to hit precisely regardless of what's actually being built. A codebase that's almost entirely orchestration logic gluing together well-tested third-party services might reasonably have proportionally more integration tests than a codebase full of complex, self-contained business logic, which leans harder into cheap, precise unit tests. The pyramid's actual claim is directional (fewer, slower tests as you move up) — not a specific ratio every project must match.

Some real codebases end up with the shape genuinely inverted — heavy reliance on slow E2E tests or even manual QA passes, with few or no fast unit tests underneath. This is a recognized, named anti-pattern (the "ice cream cone") precisely because it inherits the worst of both worlds: slow feedback (a full E2E suite, or a human, has to run before anyone learns if a change broke something) and imprecise failures (a failing E2E test still doesn't say which specific piece of logic is wrong). It usually isn't a deliberate choice — it's what happens when unit-testing discipline never got established early, and E2E tests (being closer to "just click through the app") felt like the easier place to start.

None of this says to literally write unit tests first, then integration, then E2E, in that chronological order on every feature — that's a separate question the TDD lesson addresses. The pyramid describes the proportions a healthy, mature suite tends to settle into, given the trade-offs each layer carries — a useful lens for noticing "we have 40 slow E2E tests and 3 unit tests for this feature, that's backwards" far more than a rule about what order to write things in.