The Testing Pyramid: Unit, Integration, and End-to-End Tests

The Testing Pyramid: Unit, Integration, and End-to-End Tests

The testing pyramid is a model for the relative proportion of different types of automated tests in a well-balanced test suite. It guides investment decisions in testing: more fast, cheap unit tests; fewer slow, expensive end-to-end tests. An inverted pyramid — more E2E tests than unit tests — creates slow, brittle test suites that impede delivery.

Unit Tests (Base of the Pyramid)

Unit tests test individual functions or classes in isolation — mocking external dependencies. They run in milliseconds, scale to thousands without performance issues, and pinpoint exactly where failures occur. The majority of your test suite should be unit tests. Aim for: fast, isolated, focused on a single behaviour.

Integration Tests (Middle)

Integration tests verify that components work together correctly — database queries return expected results, services interact correctly, APIs behave as expected. Slower than unit tests (may involve actual databases or services), but test behaviour that unit tests with mocks cannot catch. Fewer than unit tests, but more thorough.

End-to-End Tests (Top)

E2E tests simulate real user scenarios through the full application stack — browser, API, database. They verify that critical user journeys work correctly. Slow, brittle (sensitive to UI changes), and expensive to maintain. Should cover only the most critical user journeys — not comprehensive feature coverage. Fewer is better: focus on smoke testing key flows.

The Honeycomb (Service-Oriented)

For service-oriented architectures, the testing honeycomb (Spotify model) adjusts proportions: more integration tests, fewer unit tests, some E2E. The optimal shape depends on your architecture.