Questions › Testing

The testing pyramid

Test StrategyEasyTesting

Explain the testing pyramid. What goes in each layer, and why is the shape a pyramid rather than a rectangle?

What it tests

Whether you understand the cost/speed/confidence tradeoff across test types and how to balance them.

Approach & answer

The testing pyramid is a heuristic for how to distribute tests across three layers by cost and speed. At the wide BASE are UNIT tests: they exercise a single function/module in isolation, run in milliseconds, need no browser or network, and pinpoint failures precisely. You have the most of these because they're cheap to write and run and give fast feedback. The MIDDLE is INTEGRATION tests: several units working together — a component with its hooks and store, a service with a real (or in-memory) database, a form that validates and submits. They catch the bugs unit tests miss (wrong wiring between correct parts) but are slower and a bit more brittle, so you have fewer. The narrow TOP is END-TO-END tests: drive the whole app through a real browser like a user (Playwright/Cypress) — click, type, assert on rendered UI. They give the highest confidence that the system actually works, but they're the slowest, flakiest, and most expensive to maintain, so you keep only a handful covering critical user journeys (login, checkout). The shape is a pyramid, not a rectangle, precisely because of that gradient: push as much coverage as low as possible where tests are fast, cheap, and stable, and reserve the expensive high-confidence tests for the few flows that most need them. The anti-pattern is the 'ice-cream cone' (mostly slow e2e, few unit) — a slow, flaky suite. A common modern refinement is the 'testing trophy', which fattens the integration layer because that's where user-facing confidence per dollar is often highest for UI apps.

Use this technique when

Deciding how many of each test type to write; diagnosing a slow, flaky suite.

Code

        /\        E2E        few, slow, high-confidence, flaky
       /--\                   (Playwright/Cypress: real browser)
      /----\     Integration  some, moderate speed
     /------\                 (components+hooks, service+db)
    /--------\   Unit         many, fast, precise, cheap
   /----------\               (one function/module in isolation)

Push coverage DOWN where tests are fast & stable.
Anti-pattern: the "ice-cream cone" (mostly slow E2E).

References