The Testing Pyramid, and Where It Breaks Down

Once you know the scopes from Part 2 — unit, integration, end-to-end — the next question is how many of each. The classic answer is the testing pyramid. It's a useful default and a genuinely good starting point, and it has real gaps on modern stacks. This part covers both.

The pyramid

Picture a triangle. From bottom to top:

A wide base of unit tests — hundreds or thousands, running in milliseconds, executed on every save.
A thinner layer of integration tests — dozens to low hundreds, run on every push.
A narrow cap of end-to-end tests — a handful, covering the critical user journeys.

The reasoning is about cost and feedback. Tests near the base are cheap to write, fast to run, cheap to maintain, and when they fail they point at exactly one thing. Tests near the top are slow, brittle, and expensive to keep working — so you want just enough of them to be confident the assembled pieces work together, and no more.

Followed sensibly, the pyramid keeps your fast feedback loop fast and your maintenance burden manageable.

The ice cream cone anti-pattern

Teams that skip the discipline often end up with the pyramid inverted: a few unit tests, some integration tests, and a huge pile of slow, flaky end-to-end tests, propped up by a manual QA pass on top. The shape looks like an ice cream cone — narrow at the bottom, bulging at the top.

The symptoms are recognisable. Every release is a multi-hour ordeal. The CI run takes 40 minutes and fails randomly, so people rerun it until it's green. Nobody trusts the suite, so a red build gets a shrug. New coverage gets added at the E2E layer because that's the layer the team knows how to write, which makes the problem worse. If any of that sounds familiar, you have a cone.

Where the pyramid breaks down

The pyramid was formulated when integration tests were genuinely painful to write and run — slow test databases, heavyweight frameworks, no containers. On modern stacks that's much less true, and the strict shape has gaps:

Unit tests can over-mock. Push coverage too far toward the base and you end up replacing so much of the system with mocks that you're testing the mocks, not the code. A green suite that's mostly asserting "my function called these other functions" gives false confidence — see mock vs stub vs fake.
It ignores static analysis. Type checkers and linters catch a whole category of bugs — null dereferences, wrong argument types, unreachable code — for near-zero runtime cost. They belong at the very bottom of the model, below unit tests, and the classic pyramid doesn't mention them.
It only describes scripted tests. The pyramid has no place for exploratory testing (unscripted human investigation) or for autonomous exploration (unscripted machine coverage). Scripted E2E tests only ever check the paths someone thought to script; a strategy built purely on the pyramid has a blind spot exactly where a lot of production bugs live.

Newer shapes

The testing trophy is the best-known revision that's gained real traction: static analysis at the base, then unit tests, then a fat integration layer (bigger than the pyramid's thin band, because integration tests now deliver a lot of confidence per unit of effort on modern stacks), then a thin E2E cap. The shape is more of a rounded trophy than a triangle.

A newer idea — and one we'd argue for at Manta — is to add autonomous exploration as its own band: broad, unscripted coverage that runs alongside the scripted layers and adapts as the UI changes, without a suite to maintain. It lets the scripted E2E cap stay genuinely thin — just the exact assertions — while breadth is carried by a layer that re-explores the app each run rather than replaying stored scripts. It isn't an established industry shape the way the trophy is; it's where we think the model is heading.

The real takeaway

The lesson isn't "use the trophy instead of the pyramid" — that's just swapping one diagram for another. It's that test distribution is a deliberate design decision, made per system and per area of that system, based on where the risk is and what each layer costs to maintain for its whole life. The pyramid is a reasonable default to start from and deviate from consciously. Part 4 is about how to make those deviations — turning the picture into an actual decision.