The Test Pyramid

Purpose

The test pyramid describes a cost/confidence trade-off across three levels of test, as a shape to aim toward rather than a ratio to enforce mechanically.

The three levels

• Unit: one function or module in isolation. Fast, narrow — confirms a piece works alone, using test doubles for its dependencies.
• Integration: several real pieces working together (a route handler plus a real, in-memory database, for instance). Slower, broader — confirms the pieces actually connect correctly.
• End-to-end: the full system, exercised the way a real user would. Slowest and most brittle (a UI change can break a test that isn’t actually testing the behavior that changed), but the broadest confidence that the system works as a whole.

Contract tests (verifying a producer and consumer agree on an API’s shape) and component tests (one UI component’s behavior in isolation) sit usefully between these three main levels.

Behavior notes

• A thin UI layer over well-tested pure logic needs relatively few end-to-end tests, since most of its behavior is already covered at the unit level.
• A system with genuinely complex cross-component interactions may reasonably need more integration coverage than the “classic” pyramid shape suggests.
• Favoring lower levels isn’t about avoiding end-to-end tests entirely — it’s recognizing that a bug is usually cheaper to catch and diagnose with a fast, narrow unit test than a slow, broad one.

Common mistakes

• Treating the pyramid’s shape as a mandated ratio rather than a starting heuristic to adapt to the system actually being tested.
• Writing only end-to-end tests because they feel like “real” testing — slow, brittle, and often providing less precise failure information than a well-targeted unit test would.

Runtime notes

A testing philosophy, not a language or framework feature — applies regardless of which test runner or framework is in use.