Test pyramid

Weighting test levels effectively – how to build a stable and efficient test strategy

On this page

Definition: what is the “test pyramid”?

The test pyramid is a test case design and test strategy model that describes the optimal distribution of tests across different test levels. The concept was introduced by Mike Cohn and recommends placing the majority of tests at the lowest level — unit tests — followed by a middle layer of integration tests and a narrow top layer of end-to-end tests (E2E) or system tests. The goal of the test pyramid is to ensure a fast feedback loop, minimize testing costs, and still achieve high test coverage. The test pyramid is a core building block of modern test strategy in agile and DevOps-oriented projects and forms the conceptual foundation for the use of test automation in CI/CD pipelines.

test pyramid with system test, integration tests and unit tests

Practical examples of the test pyramid with QF-Test

QF-Test helps testers and developers put the test pyramid into practice — from automated unit tests at the base, through integration tests in the middle layer, to stable E2E tests at the top of the pyramid.

Practical recommendations:

  • Unit tests as a stable foundation: QF-Test enables the automation of unit tests directly at the component level, ensuring that the foundation of the test pyramid is covered reliably and with minimal maintenance effort. Unit tests with QF-Test

  • Integration tests for component interaction: The middle layer of the test pyramid — integration tests — can be automated efficiently with QF-Test to reliably verify interfaces and data flows between modules. Overview of test types with QF-Test

  • Regression tests for stable releases: Classic E2E regression tests form the top of the pyramid. With QF-Test, they can be executed automatically in every release cycle and integrated into existing CI/CD processes. Regression tests with QF-Test

  • Test automation as the foundation of the pyramid: Without test automation, the pyramid shape is nearly impossible to achieve. QF-Test provides a seamless automation platform for all test levels — from fast unit tests to complex GUI-based system tests. Test automation with QF-Test

  • Shift left and CI/CD integration: The test pyramid delivers its full value when tests start early in the development process. QF-Test supports the shift-left principle and integrates seamlessly into Jenkins, GitLab CI, and other CI/CD systems. Software testing basics

Goals of the test pyramid

Using the test pyramid as a planning model serves several key objectives:

  • Optimal test distribution across all test levels with minimal overall effort
  • Fast feedback through many small, fast tests at the base
  • Cost reduction through early defect detection at the unit and integration level
  • Avoidance of anti-patterns such as the ice cream cone through deliberate test planning
  • Scalability of the test strategy in agile teams and CI/CD environments
  • Increased test coverage without proportionally growing maintenance effort

These goals help testers, developers, and decision-makers to allocate testing investments purposefully and align quality assurance for long-term sustainability.

How does the test pyramid work?

The test pyramid organizes tests into three layers with different scope, execution time, and cost:

  • Base — unit tests: Many fast, isolated tests of individual functions or classes; inexpensive and easy to automate
  • Middle layer — integration tests: Verify the interaction of modules and interfaces; moderate effort, typically supplemented by mocking and stubbing
  • Top — end-to-end tests (E2E): Few, slow tests of the entire system from the user’s perspective; high execution time and maintenance effort

The anti-pattern of the “ice cream cone” describes the inversion of this distribution: many manual or E2E tests at the top, few unit tests at the bottom. The result is slow feedback loops, unstable test runs, and high maintenance costs from flaky tests. The test pyramid deliberately reverses this ratio. Combined with CI/CD pipelines and consistent test automation, the model ensures that quality issues are detected early and releases are reliably validated.

The inverted test pyramid: anti-pattern and exception

The inverted test pyramid — also known as the “Ice Cream Cone Anti-Pattern” or “software testing ice cream cone” — describes a test distribution that is the exact opposite of the ideal model: the majority of tests sit at the top level (UI tests and end-to-end tests), while the base of unit tests is thin or entirely absent. The middle layer — integration tests — is correspondingly sparse.

Why is it considered an anti-pattern?

Concentrating on the top testing level introduces several structural disadvantages in practice:

  • High costs and long runtimes: E2E tests are significantly more expensive to create, maintain, and execute than unit tests — and they scale poorly.
  • Instability (flaky tests): UI and E2E tests are sensitive to external factors such as network latency or timing issues, which frequently leads to unreliable results.
  • Late feedback: Because E2E tests run late in the development cycle, defects are discovered at a point where fixing them is far more costly than at the unit level.
  • Difficult fault localization: When an E2E test fails, it is often unclear which module or component is the root cause — making debugging time-consuming and labor-intensive.

When is it still acceptable?

Despite these drawbacks, there is one legitimate use case: projects with legacy code where adding unit tests retroactively would be too costly or technically impractical. In this context, E2E tests serve as a safety net that protects existing functionality when the codebase changes. This is a pragmatic transitional solution — not a target state. In modern, agile teams, the classic test pyramid is the goal as soon as the codebase allows sufficient testability at the component level.

Interested in QF-Test?

Tell us about yourself and we'll connect you with a QF-Test expert who can share more about our product.

Using the test pyramid

A structured approach is recommended for using the test pyramid as a planning and management tool:

Classification and relevance

The test pyramid is not a rigid rulebook but a guidance model. It gives teams a framework for how many tests make sense at each test level. The model is especially indispensable in agile projects and DevOps environments because it directly links testing effort to feedback speed. It does not replace a test strategy but forms its structural foundation.

Creation and setup

The test pyramid does not emerge from a one-time setup but through continuous prioritization: unit tests are written by developers directly alongside the code, integration tests are defined jointly by QA and development, and E2E tests are created by the QA team for critical business processes. The weighting depends on project context, risk, and the available test infrastructure.

Use in day-to-day project work

The test pyramid applies wherever recurring tests are executed automatically — especially in CI/CD pipelines. Unit tests run on every commit, integration tests follow each build, and selected E2E tests are executed as regression tests before a release. The model also helps decide which tests to prioritize when resources are limited.

Tool support

Unit tests commonly use frameworks such as JUnit, NUnit, or pytest. For integration tests and E2E tests, QF-Test provides a seamless automation platform that can cover all three pyramid layers. Seamless integration with Jenkins, GitLab CI, TeamCity, and other CI/CD systems makes QF-Test a practical tool for the entire test pyramid.

Quality criteria

A well-implemented test pyramid is characterized by short test execution times at the base, stable and meaningful test results across all layers, and a clear separation of test responsibilities. If flaky tests occur frequently or E2E tests account for the majority of test execution time, that is a reliable sign that the pyramid needs to be realigned.

Benefits of the test pyramid

  • Fast feedback loop through many automated tests at the unit level
  • Cost optimization: defects are caught early, before they surface in expensive system tests
  • Clear structure for test strategy and prioritization in agile and DevOps teams
  • Reduced maintenance effort through deliberate and sparing use of E2E tests
  • Higher overall test suite stability through fewer dependencies and flaky tests

Challenges and solutions for the test pyramid

Ice cream cone as a common anti-pattern: Many teams unintentionally end up with an inverted pyramid — few unit tests, many manual or E2E tests. The result is long execution times and a slow feedback loop. Analyze your current test distribution and invest deliberately in expanding the unit test base.

Unclear layer assignment: Without a definition of what constitutes a unit test, an integration test, and an E2E test in a given project, overlaps and gaps emerge. Establish clear criteria within the team for which tests belong to which pyramid layer, and review these assignments regularly.

Excessive dependencies in integration tests: Integration tests that involve too many system parts become brittle and difficult to maintain. Deliberately limit the scope of individual integration tests and use mocking and stubbing to isolate external dependencies.

Missing CI/CD integration: Without automated execution in a CI/CD pipeline, the test pyramid remains a theoretical model. Integrate all test levels into your build process and ensure that test results are available promptly after every commit.

Best practices

Conclusion

The test pyramid is a proven guidance model that helps teams strike a sensible balance between testing effort and testing value. By deliberately weighting unit tests, integration tests, and E2E tests, teams can build a stable, fast, and maintainable test strategy. Combined with test automation and CI/CD integration — such as through QF-Test — the model can be consistently applied and maintained over the long term, even in large and complex projects.

Frequently asked questions (FAQ)

How many tests should each layer of the test pyramid include?

There is no fixed number — but there are clear guidelines for weighting.

A rough rule of thumb is: 70% unit tests, 20% integration tests, and 10% E2E tests. The exact split depends on the project context, system architecture, and risk profile. What matters is not the absolute number but that unit tests provide the majority of coverage and E2E tests remain limited to critical user paths.

What is the difference between the test pyramid and the testing trophy?

Both models describe test distribution — with different areas of focus.

The testing trophy, introduced by Kent C. Dodds, places greater emphasis on integration tests as the most important layer — on the grounds that they better reflect real user behavior. The classic test pyramid, by contrast, prioritizes unit tests as the fastest and least expensive feedback mechanism. The two models are not fundamentally at odds; they simply emphasize different aspects depending on the system type and team context.

Can the test pyramid be integrated into existing CI/CD pipelines?

Yes — and this integration is what allows the model to deliver its full value.

The test pyramid is closely tied to CI/CD processes: unit tests run on every commit, integration tests after the build, and E2E tests before the release. QF-Test integrates seamlessly into Jenkins, GitLab CI, TeamCity, and other systems, and supports the automated execution of all pyramid layers within a single pipeline.

Interested in QF-Test?

Tell us about yourself and we'll connect you with a QF-Test expert who can share more about our product.

We use "Matomo" cookies to anonymously evaluate your visit to our website. For this we need your consent, which is valid for twelve months.

Cookie Configuration

Functional cookies

We use functional cookies to ensure the basic functionality of the website.

Performance and statistics cookies

We use Matomo for analyzing and optimizing our website. Cookies permit an anonymous collection of information that help us offering you a clear and user-friendly visit of our web pages.

Cookie details
Description Vendor Lifetime Type Purpose
_pk_id Matomo 13 Months HTTP Contains a unique, pseudonymized visitor ID internal to Matomo for recognizing returning visitors.
_pk_ref Matomo 6 Months HTTP Used to track from which website the anonymized user proceeded to our website.
_pk_ses Matomo 1 Day HTTP The Matomo session cookie is used to track the visitor's page requests during the session.
_pk_testcookie Matomo Session HTTP Used to check whether the visitor's browser supports cookies.
_pk_cvar Matomo 30 Minutes HTTP Temporarily store data about the visit.
_pk_hsr Matomo 30 Minutes HTTP Temporarily store data about the visit.