The test pyramid: which test belongs on which level

What it is

According to Fowler's bliki entry, the test pyramid became well known mainly through Mike Cohn, who described it in "Succeeding with Agile" in 2009. It arranges automated tests in layers: at the bottom, many unit tests that check a single unit in isolation within milliseconds; in the middle, integration tests that involve real neighbors such as a database or the file system; at the top, a few end-to-end tests that drive the whole system through its public interface. Going up, cost and runtime increase; going down, precision and speed increase. Fowler calls the inverted shape, a thick head of UI-level tests and almost no base, the "ice-cream cone". The article "The Practical Test Pyramid" on the same site walks through the layers using an example microservice.

Why it matters

Each layer trades realism for diagnostic value. A failed unit test names the function; a failed end-to-end test names only the system, and the search for the cause has yet to begin. Suites with too many slow tests run rarely, flake more often and are gradually ignored. The pyramid keeps feedback fast enough that developers and agents run tests after every small change.

How to apply

• Put logic into units that can be tested without infrastructure (pure functions, classes with injected dependencies), and test them exhaustively at the base, including boundary and error cases.
• Test the seams (queries, HTTP handlers, serialization, queues) in the middle layer against real dependencies running in containers, not against fakes of the database.
• Cover end-to-end only the few flows whose failure would hurt the business (login, purchase, export), and run them on the integration branch rather than on every commit.
• When an end-to-end test fails, also reproduce the same defect with a lower-level test, so that it is found faster in the future.
• Watch the runtime of the base layer; if it grows beyond a few seconds, it is worth looking for integration tests disguised as unit tests.

Pitfalls

Unit tests that replace everything with fakes end up testing the fakes. Integration tests with shared mutable state become order-dependent. The pyramid describes proportions, not absolute counts; a small service can be flat and still well tested. Fowler himself notes that the assumption "broad tests are expensive, slow and brittle" holds most of the time, but not always.