// Testing · 01
Test Pyramid
Many fast unit tests at the base, few slow end-to-end ones on top.
How it fits together
Spot it
- Suite takes 40 minutes, mostly UI tests
- Every release waits on a browser run
- A failing test does not say what broke
It costs
Unit tests can pass while the wiring is broken, so a thin top layer stays.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
The pyramid counts tests by cost. Unit tests run in milliseconds, need no network or database, and point at one class when they fail. End-to-end tests drive the whole system through its UI, take seconds to minutes each, and often fail for reasons unrelated to the change.
The ice-cream cone is the inverse: many manual or UI tests and a handful of unit tests. It is what happens when a team tests only through the front door. The suite becomes slow and flaky, so people stop running it. The testing trophy, from Kent C. Dodds, puts the weight on integration tests that run real modules together. It is a useful correction to the pyramid, not a rejection: the question is still where the cheapest test that can fail for the right reason lives.
Do not chase the shape for its own sake. A pure function with twelve input cases belongs at the unit layer, a SQL query belongs against a real database, and a checkout journey belongs in one end-to-end test. When NOT to: a small app with little logic may need only a few end-to-end smoke tests.
Ask for it
- test pyramid
- unit test
- integration test
- end-to-end test
- ice-cream cone
- testing trophy
Move rule checks out of the end-to-end suite: unit-test each validation rule and price calculation (under 10 ms each), keep one integration test per repository query against a real database, and cut the browser suite to the five critical journeys run on each merge.