Test Pyramid

## The model The test pyramid is a picture of how an automated test suite should be *proportioned* across levels. Draw a triangle. The wide base is a large population of narrow, isolated tests that exercise a small amount of code with its collaborators replaced or trivially constructed. The narrower middle band is a smaller population of tests that cross a real boundary — a genuine data store, a genuine transport, a genuine serialization step. The thin tip is a small number of tests that start the assembled system and drive it through the entry points a real user or a real client would use. Two axes carry all the meaning, and both are routinely misread: - **Width is a count.** A wide layer means *many tests*, not *important tests*. Nothing in the model says the base is more valuable than the tip; it says there should be more of it. - **Height is scope.** Going up means more of the real system is involved per test. Scope drags four other properties with it: run time per test, setup and environment cost, sensitivity to unrelated change, and the effort needed to localise a failure. ## Why the shape falls out of the economics Each test has a cost and buys a quantity of confidence. The costs stack up as scope grows. **Run time.** A narrow test typically finishes in single-digit milliseconds; a boundary-crossing test pays for connection setup and state reset; an assembled-system test pays for start-up, navigation or request sequencing, and waiting for asynchronous work to settle. Ten thousand of the first can run in the time a few hundred of the last consume. Since the value of a suite is partly the *frequency* with which a developer is willing to run it, seconds are not a minor concern — a suite nobody runs before pushing catches nothing. **Localisation.** When a narrow test fails, the fault is inside a small, named piece of behaviour, and the test name usually states which rule was violated. When an assembled-system test fails, the candidate causes include every component on the path plus the environment, the data, the deployed versions and the timing. Diagnosis time, not authoring time, is what makes the top layer expensive over a system's life. **Stability.** The more moving parts a test touches, the more ways it can fail without the code being wrong: timing, shared state, network, third-party availability. Nondeterministic failures on unchanged code cost trust, and lost trust in a suite converts real failures into ignored ones. **Realism.** This is the one property that improves as you go up, and it is why the tip exists at all. Narrow tests can all pass while the assembled system is broken — wiring, configuration, versions and cross-component assumptions are exactly what the base cannot see. The pyramid does not say "skip that"; it says buy the minimum amount of it that covers the risk. Put those together and the shape is a cost-per-unit-of-confidence argument: **prefer the cheapest level that can catch a given class of defect, and reserve the expensive levels for the defects only they can catch.** ## What the model does not claim Ratios such as 70/20/10 are illustrative conventions that circulate with the picture; they are not measured findings and no serious version of the model fixes them. Treating them as a target produces its own pathology — teams inflate the base with near-duplicate tests over trivial code to hit a ratio, which adds run time and maintenance without adding coverage of any risk. The model also does not define the levels for you. Where the boundary of a unit is drawn, and how wide an integration test may go before it stops diagnosing anything, are separate decisions the pyramid assumes have already been made. Two teams with the same shape can mean quite different things by each band. Finally, it is a *default*, not a law. The model came out of agile testing practice at a time when suites were dominated by slow, brittle, record-and-playback checks driving a user interface, and its main argument was directional: push checking down. It is deliberately silent on architectures where the interesting risk genuinely lives at a boundary rather than inside a component. ## Reading a suite against it A quick health check does not need a tool. Compare, per level, the number of tests, the wall-clock share of the run, and the share of genuine defects each level has caught. A base that is wide but catches nothing is padding. A tip that is thin but produces most of the failures — and most of the *false* failures — is a signal that risk is concentrated where feedback is slowest. The pyramid is useful precisely because it turns those observations into one comparable picture.