Test Pyramid

The pyramid is an economic argument, not an aesthetic one. Test cost has three components — runtime, maintenance and diagnostic effort — and all three rise sharply with scope. A unit test fails in milliseconds and names the broken function; an end-to-end test fails in eleven minutes and tells you that checkout is broken somewhere across nine services.

The shape follows from that. Push each check to the narrowest scope that can still detect the defect class you care about, and reserve broad tests for the few paths where the integration itself is the risk.

Two failure shapes are worth naming. The ice cream cone inverts the pyramid — mostly end-to-end, some integration, few unit tests — and produces suites that take hours, fail randomly and are eventually ignored. The hourglass has healthy unit and end-to-end layers with nothing in between, which happens when teams find integration tests awkward and skip the layer where most real defects in distributed systems actually live.

The honest caveat: the pyramid was described for systems whose complexity sat inside the process. In a microservice estate, much of the risk moved to the boundaries, which is the argument for contract testing rather than for more end-to-end tests.