Test pyramid
The shape of a healthy test suite: many cheap unit tests at the base, fewer integration tests, a thin cap of slow end-to-end tests.
See it
What it is
A picture of how a test suite should be proportioned, from Mike Cohn's 'Succeeding with Agile' and popularized by Martin Fowler. Wide base: many unit tests, milliseconds each, pinpoint failure messages. Middle: fewer integration tests that check real pieces wired together. Thin cap: a few end-to-end tests driving the real app in a browser. The shape follows cost, because as you climb, tests get slower, flakier, and vaguer about what broke, while each one buys more confidence that the system genuinely works.
Flip it over and you get the ice cream cone: hundreds of brittle UI tests on top of almost no unit tests, a suite that takes forty minutes and fails for reasons nobody can decode. That is the failure mode the pyramid was drawn to prevent.
The pyramid is a heuristic about cost, not a moral rule, and it has a well-known rival: Kent C. Dodds's testing trophy, which fattens the integration layer on the argument that modern tools made integration tests cheap and most real bugs live in the seams between units. Both agree on the actual point: buy confidence at the lowest level that can give it to you. If your bugs keep coming from integration, your suite should get fatter in the middle no matter what shape the diagram has.
Ask AI for it
Audit this repository's tests against the test pyramid. Count the tests at each level (unit, integration, end-to-end), report the current ratio and the runtime each level contributes, and say whether the suite is pyramid-shaped or an ice cream cone. Then propose specific moves: which E2E tests cover logic that a unit test could pin down instead, which uncovered seams need integration tests, and which five E2E journeys are genuinely worth keeping. Keep the whole suite under a stated time budget.