The testing pyramid: Strategic software testing for Agile teams

The testing pyramid model fits software testing into an efficient hierarchical structure. By focusing on unit tests at the base, integration tests in the middle, and end-to-end tests at the top, the pyramid directs most testing effort toward tests that are fast, reliable, and easy to maintain. This leads to quicker iterations, improved code quality, and more stable releases.

This article covers the structure and benefits of the testing pyramid, its role in continuous integration and continuous delivery (CI/CD) processes, and practical strategies for implementing it in Agile software development workflows.

What is the testing pyramid?

Although various people have shaped and popularized the concept of the testing pyramid, its most notable proponent was software engineer and Scrum pioneer, Mike Cohn. He introduced the testing pyramid in his 2009 book Succeeding with Agile: Software Development Using Scrum.

Cohn proposed the testing pyramid could address challenges in managing automated testing in software development, particularly when following Agile methodologies. The key idea was to encourage developers and testers to think about different levels of testing and to balance their efforts across these levels. A common rule of thumb is a roughly 70/20/10 distribution: 70% unit tests, 20% integration tests, and 10% E2E tests, though the exact ratio depends on the project.

• Unit tests: Forming the base of the pyramid, these tests focus on a single functionality and small units of code. They are typically numerous but quick to write and run.

  Teams should run unit tests frequently, ideally as part of an automated continuous integration process, to ensure that new changes don’t break existing functionality and to maintain a high standard of code quality throughout the development lifecycle.

• Integration tests: Comprising the middle of the pyramid, these tests check the interaction between different modules or external systems. Compared to unit tests, they are fewer in number, more expensive, and slower to run.

  Teams should run integration tests less frequently than unit tests, typically at key points during the development cycle such as after significant features or changes have been integrated into the main branch. This ensures that while the more detailed and granular unit tests run with every small change, integration tests verify the system’s overall coherence and functionality at critical stages — balancing thoroughness with efficiency.

• End-to-end (E2E) tests: Sitting atop the pyramid, E2E tests involve checking the entire application as end users would experience it, including user interfaces, APIs, databases, and other services. They are the most complex and have the longest run time.

  Teams should run E2E tests at significant milestones, such as before releases. Given their broader scope, E2E tests are more time-consuming and resource-intensive than both unit and integration tests. They run less frequently to validate the entire application’s workflow from start to finish under conditions that mimic real-world usage.

The following diagram shows the pyramid’s three key layers and their focal areas in the testing process.

As open-box tests, the constrained and focused unit tests give the tester complete awareness of the code’s internal workings and structure. Comparatively, developers often conduct integration and E2E tests without detailed knowledge of each component’s internals — in other words, as closed-box tests.

The testing pyramid provides a roadmap for quality assurance throughout the Agile software development lifecycle.

Benefits of the testing pyramid

The testing pyramid encourages a balanced and targeted approach to automated testing. It aims to prevent over-reliance on any one type of test, such as E2E tests, which are often more brittle and expensive to maintain. The model helps teams catch more bugs at the lower levels of the pyramid, where they are cheaper and easier to fix. At the same time, it ensures sufficient E2E testing to confirm that the system functions correctly.

This model also promotes efficient resource allocation. Teams run numerous low-cost unit tests but fewer complex and pricey E2E tests. The pyramid structure speeds up feedback — starting with numerous unit tests lets teams quickly identify and resolve issues.

Finally, following the testing pyramid model ensures test coverage from individual components to the system as a whole. This aligns closely with Agile principles, improving software development quality while maintaining speed and adaptability.

Criticisms and alternative models

The testing pyramid isn’t without its critics. Some argue it oversimplifies testing strategy and leans too heavily on unit tests, which can create a false sense of security when integration-level bugs go undetected. Others point out that its original assumptions — particularly that UI tests are inherently slow and brittle — have become less true as tools like Playwright and Cypress have matured.

Several alternative models have emerged. The testing trophy, popularized by Kent C. Dodds, places the most weight on integration tests and adds static analysis (linters, type checkers) as a base layer. The test diamond gives roughly equal emphasis to unit and integration tests. Spotify’s testing honeycomb is tailored to microservice architectures, where most complexity lives in service-to-service interactions rather than within individual services.

It’s also worth knowing the ice cream cone anti-pattern: a test suite top-heavy with slow E2E tests and thin on unit tests. The pyramid was designed specifically to prevent this inversion.

None of these models are universal prescriptions. The right shape depends on the project’s architecture, risk profile, and team capabilities. The pyramid remains a strong default, especially for teams building a testing practice from scratch.

The testing pyramid in practice

To better understand how to apply the testing pyramid model, consider the following practical example: developing a project management tool.

Unit testing example

The unit testing stage of our project management tool involves testing individual components or functions in isolation. For example:

• Task creation logic: Validating the feature for adding a new task to ensure it incorporates all required details, such as title, description, and deadline
• User authentication methods: Ensuring the user login feature correctly validates user credentials and handles errors like incorrect passwords or usernames
• Notification system: Checking that the notification system generates the correct alerts for task deadlines or updates

These tests would mock or stub dependencies like database calls or external services to focus solely on the logic of the component being tested. They are automated and run frequently during development to catch and fix bugs early.

Integration testing example

At the integration testing stage, the focus shifts to how different components of the project management tool interact. For example:

• Task and calendar integration: Test how new tasks appear in the project calendar, verifying that tasks show up on the correct dates and that updates such as changing a due date are reflected in the calendar.
• User permissions: Ensure that changes made by one user (like updating a task status) are correctly reflected for other users with access to the same project, testing the integration between user roles, task management, and real-time updates.

These tests involve a combination of components and require a more involved setup, possibly including real database access or API calls. They run less frequently than unit tests, typically after a group of components has been developed or updated.

E2E testing example

E2E testing evaluates the project management tool’s entire workflow. In the context of a project management tool, this could involve:

• Project lifecycle: Test the application’s ability to handle a project from inception to conclusion by creating a new project, adding team members, creating tasks, updating task status, and archiving or completing the project.
• Collaboration features: Check the tool’s collaborative capabilities and real-time update features by simulating multiple users working on the same project, including assigning tasks, commenting on tasks, and tracking project progress.

E2E tests typically use tools that simulate user interactions with the application’s interface, such as clicking buttons, filling out forms, and navigating through the application. They require a fully deployed application environment and run at critical milestones, such as before a release or after significant features have been added to the application.

CI/CD and the testing pyramid

CI/CD automates the process of building, testing, and deploying code, giving teams complete control over how and when tests and other development tasks run. The iterative nature of CI/CD processes means they integrate well with the testing pyramid model, particularly in Agile environments.

A typical CI/CD pipeline runs unit tests on every commit to a development branch, providing immediate feedback to help developers catch issues early in the development cycle.

Integration tests typically run after unit tests have passed and before a merge into the main branch, ensuring that different components work well together before significant changes are integrated into the broader application.

End-to-end (E2E) tests are usually run after all changes have been merged into the main branch and before deployment to staging or production environments, serving as a final check that the application meets all requirements and functions correctly in an environment that closely mimics the production setting.

This approach benefits Agile teams by supporting rapid development and deployment. The pyramid’s testing strategy ensures each deployment’s speed and reliability — both of which matter for Agile teams aiming to consistently ship high-quality software.

For more information on how to arrange tests across the development process, read The path to production: How and where to segregate test environments.

Implementing the testing pyramid in development workflows

Integrating the testing pyramid into software development workflows requires a strategic approach. Here are some tips for putting this model into practice:

• Start with unit testing: A strong suite of unit tests forms the pyramid’s foundation. Developers should write unit tests alongside new code, following practices like test-driven development (TDD).

• Focus on integration tests: After establishing unit testing and TDD as a fundamental practice, teams should develop integration tests to ensure that various components of the application work well together. These tests bridge the gap between unit testing and E2E testing.

• Strategically implement E2E tests: Due to their complexity and resource demands, E2E tests require careful planning and implementation. Teams should only implement them to cover the application’s critical user journeys and major functionalities.

• Regularly review and adjust: Teams should continuously assess the test suite’s effectiveness and efficiency. The balance of tests may need to shift as the project evolves — adding more tests where needed and refining existing ones.

• Automate testing in CI/CD pipelines: Automation tools help keep testing processes consistent and efficient. Tools like CircleCI can automate test runs, making sure they happen on every relevant trigger without manual intervention.

• Educate and collaborate: All team members should understand the importance and role of each tier in the pyramid. A collaborative environment where developers, Quality Assurance (QA) engineers, and other stakeholders work together to maintain and improve the test suite leads to better outcomes.

Conclusion

The testing pyramid is a widely used model in Agile software development, providing a clear and efficient approach to testing. Its tiered structure of unit, integration, and E2E tests gives teams a balanced testing strategy that aligns closely with Agile principles.

The model promotes efficient use of resources by emphasizing a high volume of low-cost unit tests and progressing to fewer, more complex tests. It also supports CI/CD workflows, helping teams maintain the speed that modern software development demands.

To start using the testing pyramid in practice and improve software quality across the development lifecycle, sign up for a free CircleCI account today.