Test pyramid

The test pyramid is a guideline for how to distribute automated tests across levels. The wide base is unit tests, which are fast, cheap and precise. The middle is integration or service tests. The narrow top is end-to-end tests through the UI, which give the most realistic confidence but are the slowest and most fragile. The idea, popularized by Mike Cohn, is to push each check down to the lowest level that can catch the problem.

Example

Take a rule: “orders over $100 get free shipping”.

• Unit: test the shipping-cost function with $99.99, $100.00 and $100.01. Milliseconds each, no browser.
• Integration/API: call POST /orders with a $120 cart and assert the response has shipping: 0. This proves the rule is wired into the service.
• End-to-end: one UI test that checks out a qualifying cart and sees “Free shipping” on the confirmation page.

You do not need ten UI tests for the boundary values. The unit tests already prove the arithmetic.

Why the shape matters

Higher-level tests touch more components, so a failure tells you less about where the bug is. They also need browsers, environments and test data, which makes them slower and more prone to flakiness. A suite that is mostly UI tests (the “ice-cream cone” anti-pattern) runs for hours, fails for reasons unrelated to the change, and gets ignored.

Criticism and alternatives

The pyramid is a heuristic, not a quota. Alternatives such as the “testing trophy” put more weight on integration tests, arguing that heavily mocked unit tests can pass while the real system is broken. Both models agree on the important part: keep slow, broad UI tests few and focused on critical journeys, and get most of your confidence from faster layers. Choose the balance from where your bugs actually come from, not from a fixed ratio.