The test pyramid: what it is and where it falls short

01The classic pyramid

       /\
      /E2E\        ← few, slow, expensive
     /----\
    / Integ \      ← some
   /--------\
  /   Unit   \    ← many, fast, cheap
 /------------\

The argument: unit tests are fast and cheap, so write a lot of them. Integration tests are slower, so write fewer. End-to-end tests are slowest and flakiest, so write the fewest.

02Where it gets right

Fast tests (unit) catch most regressions cheaply.
Slow tests (E2E) are precious — invest where the user-facing risk is highest.
Flaky E2E tests destroy trust faster than missing E2E tests.

03Where it falls short

It pretends manual and exploratory testing don't exist.
It encourages people to write low-value unit tests just to grow the bottom.
For some products (UI-heavy SaaS), more integration and fewer pure unit tests fit better.

04A useful modern variant

Write enough unit tests to cover non-obvious logic, enough integration tests to cover the seams between components, and a small honest set of E2E tests for the critical user paths. Pair with exploratory testing for what automation can't see.

05Related

06Frequently asked questions

Is the test pyramid still relevant?

As a default, yes. As dogma, no. Modern alternatives like the testing trophy (more integration, fewer unit) match what teams actually find useful.

Where does manual testing fit on the pyramid?

It does not. The pyramid is about automated tests. Manual testing — exploratory, accessibility, mobile-on-real-devices — sits alongside, not above.