Test pyramid

The test pyramid is a heuristic about proportions. Most automated checks should be small and fast, exercising a unit of logic in isolation. A smaller layer should cover components working together, against real infrastructure wherever that is feasible. A very small layer should drive the assembled system the way a person does. The shape follows from cost: the more of the stack a test covers, the slower it runs, the more maintenance it demands, and the less precisely it identifies what broke.

The inverted version is the common failure, and it is expensive rather than merely inelegant. A suite made mostly of end-to-end tests takes an hour to finish, so it cannot gate a pull request. It fails for environmental reasons, so people stop reading the output. Each failure names a screen rather than a cause, so somebody has to debug the product to discover what the test was trying to say. Teams arrive there honestly, because an end-to-end test is the easiest thing to write against a system that was never built with testability in mind.

Using it without arguing about the diagram

• Treat it as a question about ratios, not a taxonomy. The valuable habit is asking whether a new test could live one layer down and return an answer in milliseconds.
• Push individual cases downwards rather than whole features. Every validation rule checked through a browser is a rule that could have been checked in a unit test a thousand times faster.
• Reserve the top layer for journeys. End-to-end coverage belongs on the handful of paths that earn money, exercised in the order a customer meets them.
• Accept that the ideal shape depends on the architecture. A service that is mostly integration glue has fewer meaningful units to isolate, and the alternative shapes people propose for those are the same principle with different proportions.

The pyramid is a claim about feedback speed rather than about categories of test, and any arrangement that returns a trustworthy answer sooner is honouring it.