20 Oct 2026 Test automation pyramid: where each test belongs so your suite stays fast
In short: The test automation pyramid is a model for spreading your automated tests over three layers. You want many fast unit tests at the bottom and fewer API tests in the middle. On top sits a small set of UI tests. A suite with that shape runs in minutes, fails for clear reasons and keeps up with your releases.
A test suite that needs all night to run slows down every release it should protect. Most slow suites have the same shape. There are hundreds of UI tests that click through screens, a thin layer of API tests, and a pile of manual checks on top. The test automation pyramid is the simplest way to see what is wrong with that shape. It also shows how to fix it, one test at a time.
What is the test automation pyramid?
The test automation pyramid is a model that shows how to divide automated tests over three layers. Mike Cohn came up with it, and Martin Fowler made it widely known. At the bottom sit unit tests. They check one small piece of code, such as a price calculation, and run in milliseconds. In the middle sit API and integration tests. They check whether parts of the system work together, for example whether an order call stores the right data. They skip the screen, so they are fast and stable. At the top sit UI tests, also called end-to-end tests. They click through the app the way a user would. They give the most confidence per test, but they are slow and break when a screen changes. The rule of thumb is simple. Write many tests at the bottom, fewer in the middle and only a few at the top.
The shape matters because of feedback. A developer who learns within minutes that a change broke something can fix it right away. One who learns it the next morning has already moved on.
Why do so many test suites end up upside down?
Most suites grow top-heavy because UI tests are the easiest place to start. A tester can script a user flow without knowing the code behind it. Each bug that slips through gets a new end-to-end test. After a year, the suite looks like an ice cream cone. It has lots of UI tests, few API tests, few unit tests, and manual testing on top of it all. At e-commerce clients we see this pattern often. Long UI test sets slow down the pipeline, and API and UI tests exist side by side without a clear plan. The API tests are there, but they aren’t used for what they do best: guarding business logic and integrations.
The cone costs you in four ways.
- Slow feedback. A full UI run takes hours, so it only runs at night or before a release.
- Noise. UI tests depend on timing, browsers and test data, so many turn into flaky tests that fail without a real bug.
- Double work. The same rule gets checked through the screen in ten different flows.
- Upkeep. One changed button can break dozens of tests at once.
Which tests belong on which layer?
Put each check on the lowest layer that can still catch the problem. If a check is about a rule, such as a discount or a tax rate, it belongs below the screen. If it is about whether a real user can finish a journey, it belongs on top. This one question sorts most tests. It also keeps your UI layer small, because most of what UI tests check is really logic. The table shows the idea with a webshop as the example.
| Layer | What it checks | Example | Typical speed |
|---|---|---|---|
| Unit | One rule or calculation in the code | The VAT on an order line is right | Milliseconds |
| API and integration | Business logic and the links between systems | The order API refuses an expired discount code | Seconds |
| UI or end-to-end | A full journey through the screens | A customer logs in, orders and pays | Minutes |
The middle layer is where most teams can win the most. API tests check business logic without a browser, so they are fast and rarely flaky. That makes API testing the best place to guard prices, discounts and stock rules. For code examples per layer, Ham Vocke’s practical test pyramid is a good long read.
How do you move a top-heavy suite toward the pyramid?
You rebalance a suite step by step, not with a big rewrite. Start with the tests that cost you the most time, and move their checks down one layer at a time. Keep the suite running while you work, so you never lose the safety net. These steps work in most teams.
- Measure. List your UI tests, how long each one runs, and how often it fails without a real bug.
- Find the doubles. Look for the same rule checked through the screen in many flows.
- Push checks down. Rewrite rule checks as API or unit tests. Keep one UI test per key journey.
- Split the runs. Run the fast layers on every change, and the full UI set at night.
- Delete with care. Remove tests that no longer guard a real risk.
Splitting fast and heavy checks pays off quickly. In our Data Warehouse case, functional tests ran on small, production-like datasets. The heavy data quality checks ran on their own, on big datasets. Automated test runs went from days to under 30 minutes.
One trade-off to name: the pyramid is a guide, not a law. Some systems have little logic of their own, such as a shop on a SaaS platform. There, more weight sits in API and end-to-end tests, and that is fine. Google’s testers made a similar point in Just Say No to More End-to-End Tests. And no layer replaces people. Exploratory testing from a real user’s view and acceptance testing by business users stay human work.
What this means for your team
Rebalancing a suite is not a one-off cleanup. Every new feature adds tests, and someone has to decide where they go. Someone also has to keep them reliable and remove what no longer matters. In many teams that work lands on whoever has time, and nobody has time during a release. So the cone slowly grows back.
That ongoing work is what we do with Test Automation as a Service. Together with your team, we build a compact suite with the most risk coverage in the least run time. Rules sit on the API and unit layers, and a small UI set covers the journeys that matter. Your tests run every night, and we keep them reliable. The suite stays yours, documented and transferable, and your team decides what ships.
Want to start on your own first? Take your ten slowest UI tests this week. For each one, write down which rule it really checks, and whether an API test could check it faster.
A fast, trusted test suite that runs every night, while your team stays in control.
Frequently asked questions
Who came up with the test pyramid?
Mike Cohn described it in his book Succeeding with Agile. Martin Fowler and others made it widely known. The idea has stayed the same: many small, fast tests and few slow ones.
How many UI tests should you have?
There is no fixed number. Aim for one UI test per key user journey, such as logging in, ordering and paying. Check everything else on a lower layer where you can.
Is the test pyramid still relevant?
Yes, as a guide. Tools have made UI tests faster, but they are still slower and more fragile than API tests. The pyramid helps you decide where a new test should go.
What is the difference between the test pyramid and the testing trophy?
The testing trophy puts more weight on integration tests and less on unit tests. It comes from front-end teams. Both models agree on the main point: keep the slow UI layer small.