Test automation pyramid: ratios, costs and when to break it

What the shape is actually saying

Three claims sit inside the pyramid. First, tests closer to the code are cheaper to write, faster to run and more precise about what broke. Second, tests farther from the code catch a class of defect the lower layers cannot: integration mistakes, configuration, the wiring between components. Third, because the upper layers are more expensive and less precise, you want as few of them as still catches that class. The shape follows from the three claims. It is not an aesthetic preference and not a rule about percentages, which is why the numbers below are called a starting point.

A useful reframing: every behavior should be checked at the lowest layer that can observe it. A rounding rule belongs in a unit test. A permission check across two services belongs in an API test. Whether the checkout button is visible after login belongs in a UI test, and there should be exactly one of those, not forty.

Layer ratios and what each costs

The cost column is the one to argue from. A UI test that takes 4 hours to write and 30 minutes a month to keep alive costs the same as roughly 10 API tests or 50 unit tests over a year. If the same defect could have been caught lower down, that UI test is displacing 50 checks that would have run in the time it takes to start a browser.

The 70/20/10 starting point and how to adjust it

Start at 70 percent unit, 20 percent service, 10 percent UI by count, then move the boundaries using two observations from your own data. If most escaped defects in the last two quarters were integration faults (wrong status code, broken message format, permission misapplied), grow the API layer toward 30 percent and shrink unit. If most escapes were logic errors inside a component, the unit layer is under-built and the fix is coverage there, not more UI tests. Look at where coverage is thin per layer rather than in aggregate; a system can report 80 percent line coverage and have no test that crosses a service boundary.

Count by execution time too. A healthy suite spends about half its wall-clock time in UI tests even though they are a tenth of the count. If UI tests consume 90 percent of run time, they are also consuming 90 percent of your maintenance and the ratio by count is misleading you.

The ice cream cone: how suites invert

Nobody designs the cone. It grows when a testing team, given a browser automation framework and no access to the code, automates the manual regression suite screen by screen. Two years later there are 1,200 UI tests, a 6 hour run, a 15 percent flaky rate and developers who merge without waiting for the result. The tell-tale signs, in the order they appear: UI tests exceed 30 percent of the suite, the nightly run is the only run, a rerun-on-failure step is added to the pipeline, and a quarantine list grows without a limit.

Recovery is not deletion. Take each UI scenario and ask what it is really checking. Push the data and logic assertions down into API and unit tests, keep one UI test per critical journey, and delete the rest once the lower tests are green. Teams that do this typically cut UI count by 70 to 80 percent while keeping defect detection flat.

When the pyramid is the wrong shape

The pyramid assumes the risk is in the logic. Two kinds of systems break that assumption.

• Data-heavy systems (reporting, pipelines, billing runs). The risk is in the data flowing between stages, not in any one function. The right shape is a wide integration layer: many tests that push known input through the real pipeline and compare output to a golden set, with a thin unit layer for transformations and almost no UI. Some teams call this a diamond.
• UI-heavy products (design tools, editors, anything where the interface is the product). Logic is thin and the behavior users care about lives in rendering and interaction. Component tests that mount one UI component in isolation take the place of unit tests, and the UI layer legitimately grows to 20 or 30 percent.
• Thin front ends over third-party services. Little owned logic, heavy integration risk. Contract tests against each external dependency carry the suite; unit tests are few because there is little to unit test.

The honeycomb or trophy variants you will see described elsewhere make the same point generically: for a system built mostly from integration, the middle layer is where most tests belong, with a small unit base and a small end-to-end top. Pick the shape from your defect history, then defend it with the same cost table.

Making the ratio stick

A ratio survives only if something enforces it. Add three checks to the definition of done: every new behavior has a test at the lowest layer that can observe it, every new UI test is justified by a journey not already covered, and UI test count is reported per sprint. Put the per-layer counts and run times on the same dashboard as pass rate. When the UI layer grows faster than the API layer for two sprints running, the automation strategy needs a conversation, not another test.

This guide is part of the test automation hub. It is best read alongside test automation strategy and continuous testing, which cover the neighbouring questions.