The test pyramid and where each test belongs

What it is

The test pyramid is a heuristic for the proportions of a test suite: a broad base of unit tests that run in milliseconds and isolate one unit, a middle layer of integration tests that exercise real collaborators such as a database, and a small top of end-to-end tests that drive the whole system through its public interface.

Why it matters

Each layer trades speed and precision for realism. A failing unit test names the function; a failing end-to-end test names the system. Suites that invert the pyramid become slow, brittle and hard to diagnose, which the cited article describes as the ice-cream-cone anti-pattern.

How to apply

• Put logic in units that can be tested without infrastructure; test them exhaustively at the base.
• Test the seams (queries, HTTP handlers, serialisation) in the middle layer against real dependencies in containers.
• Keep end-to-end tests to the critical journeys and run them on the integration branch, not on every keystroke.
• When an end-to-end test fails, add a lower-level test that reproduces the same failure faster.

Pitfalls

Unit tests that mock everything test the mocks. Integration tests that share mutable state become order-dependent. The pyramid describes proportions, not a required count; a small service may have a flat shape and still be well tested.