What is the test pyramid, and is it still the right model for your system?

The shape and the argument behind it

The pyramid puts many fast unit tests at the base, fewer integration tests in the middle, and a handful of end-to-end tests at the top. The distribution is not the point; the reasoning is, and it comes down to two curves that both worsen as you climb.

Cost rises. A unit test runs in a millisecond with no infrastructure. An integration test needs a database and takes a second. An end-to-end test needs the whole system deployed, takes minutes, and someone maintains the environment it runs in. A thousand of the first is a few seconds; a thousand of the last is not a thing you can run.

Diagnostic value falls. A failing unit test names the function that broke. A failing end-to-end test tells you that logging in and buying something no longer works, and finding out why is an investigation. The pyramid is as much about how long a failure takes to fix as about how long the suite takes to run, and this is the half that gets left out.

Flakiness rises, which is the compounding one. Every additional component is another chance for a timeout, a race, or a dirty fixture. A test that fails one run in twenty stops being read as a signal, and once a team learns to re-run rather than investigate, the suite has stopped functioning as a gate no matter how much of it there is.

Where the argument stops holding

The pyramid is a claim about where the risk in a typical system sits: in the logic. When that claim is false for your system, following the shape anyway produces a suite that passes while the product is broken.

A service that is mostly glue — read a request, query a database, map the result, return it — has almost no logic to unit test. Mock the repository and you are testing your mock. The defects in that service are in the query, the schema mapping, the transaction boundary and the serialisation, none of which a unit test with a mocked database can see. Its correct shape is integration-heavy, and a well-earned "diamond" with a thick middle is the right answer rather than a compromise.

The same applies to an event-driven pipeline, where the interesting failures are ordering, redelivery and schema evolution across a boundary, and to anything whose value is in a UI interaction rather than in a calculation behind it.

The general rule: test at the level where the risk lives. The pyramid is a good default because for most systems the risk is in the logic. It is a default, not a law, and a candidate who can say where it does not apply is demonstrating more than one who recites it.

Define the layers before arguing about the ratio

Teams argue about the pyramid while meaning different things by every layer, which makes the argument unresolvable. One person's unit test mocks everything including the collaborators in the same module; another's touches an in-memory database and is still called a unit test.

The definition that matters in practice is not about scope but about what a failure implicates. A test whose failure points at one unit of code is a unit test whether or not it touched a real object. A test whose failure could be any of four components is an integration test even if it runs in the same process. Agree that first, and the ratio conversation becomes possible.

The ice-cream cone

The inverted shape — a mass of slow UI tests, a few integration tests, almost no unit tests — is common enough to have a name, and it is worth being precise about why it happens, because "the team was undisciplined" is usually wrong.

It is what you get when tests are written after the fact, often by a separate group, against a system that was not built to be tested in pieces. If the business logic is embedded in controllers and UI handlers, there is nothing to unit test without refactoring, and the only seam available is the browser. The cone is a symptom of the production code's structure, not of the test authors' preferences.

Which tells you how to get out of it, and it is not "write more unit tests". It is to extract the logic into something callable, then test it directly. Each extraction moves a slice of coverage down the pyramid and lets you delete the UI test that was covering it. Incremental, and it works, but it is a production-code project rather than a testing one, and framing it that way to a stakeholder is more honest than promising a testing cleanup.

What the top is actually for

Keep the end-to-end layer, and keep it small and deliberate. Its job is not coverage — it is to prove that the pieces are wired together in the deployed environment, which no lower layer can establish. A handful of critical journeys, run against a real deployment, answering "is the system assembled correctly".

Contract tests are what let that number stay small. Verifying each side of an integration against a shared contract catches the mismatch that end-to-end tests are usually there to catch, at a fraction of the cost and with a much clearer failure message.

The pyramid is an argument about where your defects are, not a rule about ratios. Put the tests where the risk is, and if that is not the logic, the shape should not be a pyramid.