What is the test pyramid, and is it still relevant?

The test pyramid, popularised by Mike Cohn and later by Martin Fowler’s writing, says you should have many small, fast, isolated tests at the bottom (unit), fewer tests that exercise components together (integration or service/API), and very few broad end-to-end tests through the UI at the top. The reasoning is economic: lower tests are faster, cheaper to write and maintain, more deterministic, and point precisely at the failing code. Higher tests give more realistic confidence but are slower, more brittle and harder to diagnose.

The layers

• Unit: a function or class in isolation, milliseconds each, thousands per suite. Owned by developers.
• Integration / service / API: a service with its database, or two components talking to each other, or an HTTP API tested directly. Seconds each.
• End-to-end / UI: a real browser driving the deployed system across services. Tens of seconds each, sensitive to environment and timing.

The anti-pattern: the ice-cream cone

Many teams end up inverted: lots of manual and UI tests, few unit tests. The symptoms are familiar: suites that take hours, flaky failures nobody trusts, and bugs found late. A large share of what those UI tests check (validation rules, calculations, permissions) could be tested far more cheaply at the API or unit level.

Is it still relevant?

The principle is: push each check down to the lowest layer that can catch the defect with confidence. That remains sound. The shape is debated:

• Testing trophy (Kent C. Dodds, popular in front-end): static analysis at the base, then a thin unit layer, a large integration layer, and a small E2E cap. The argument is that integration tests of components give more confidence per test.
• Testing honeycomb (described by Spotify engineers for microservices): mostly integration tests of each service against its real dependencies, few implementation-detail unit tests, few integrated-system tests.
• Contract tests (for example Pact) replace many cross-service E2E tests in microservice architectures.

Tooling also shifted the economics. Modern browser tools like Playwright are faster and less flaky than older stacks, and containers make real databases cheap in integration tests. That makes higher layers more affordable, but not free.

How I apply it

For each risk I ask “where is the cheapest place this could be caught reliably?”

• Tax calculation rules: unit tests, table-driven.
• Order API returns correct status codes and persists data: API/integration tests.
• A customer can browse, add to cart and pay: a handful of E2E journeys.
• Visual layout: targeted screenshot comparisons, not assertions in every E2E test.

Then I look at the actual distribution in the suite and the runtime of each layer, and push tests down when a layer becomes slow or flaky.

What interviewers look for

• Correct layers and the cost/confidence trade-off behind them.
• Awareness of the ice-cream cone and how to fix it.
• Nuance: trophy, honeycomb, contract testing, and that architecture changes the right shape.
• A practical rule for placing a given test.