The “test pyramid” has been repeated for decades as gospel in software engineering.
It relies on a base of unit tests, a middle layer of integration tests, and a narrow top layer of end-to-end (E2E) tests.
But that model is a comfortable lie.
In modern distributed systems, integration and E2E tests are the same thing.
The only difference is who the final client is.
If the client is another internal module, we call it integration.
If the client is the user, we refer to it as E2E.
But in both cases, what we’re truly doing is testing a real end-to-end flow.
The Origin of the Pyramid
The traditional pyramid was built to represent cost and speed:
Unit tests – fast and cheap.
Integration tests – slower, connect components.
E2E tests – full system validation, slowest and most expensive.
That abstraction worked in monolithic systems.
But in a world of microservices, APIs, queues, and asynchronous flows, it’s obsolete.
Almost every feature today crosses multiple boundaries — so there’s no “middle layer” anymore.
There are just different scopes of end-to-end validation.
Unit Tests
Initial cost:
Low — native tools make them easy to start.Hidden cost:
High — brittle mocks and excessive isolation lead to painful refactors.When valuable:
For deterministic logic and business rules.
For side-effect-free code.
When misleading:
When used to fake coverage confidence.
When masking broken contracts or API mismatches.
Useful, but they don’t prove real system quality.
Integration and E2E: Two Names, Same Thing
Both exist to validate how a system behaves from input to outcome under realistic conditions.
The only distinction is the client being tested:
If the client is internal (another service, a repository, a queue consumer) → call it integration.
If the client is external (user, frontend, or API consumer) → call it E2E.
In both cases, you:
Spin up real dependencies (DB, Redis, HTTP APIs).
Execute a complete flow.
Assert contracts and observable outputs.
Technically, there is no meaningful boundary between them.
They differ in perspective, not implementation.
The pyramid collapses because its middle and top layers are the same category of test with different clients.
Real Cost and ROI
The pyramid assumes a clear separation between types of tests.
In practice, E2E is just an integration test with a more external client.
The “Test Diamond” and Beyond
A more accurate modern model is a test diamond:
A slim base of strategic unit tests.
A dense center of integration and contract tests.
A narrow top of E2E tests that truly matter.
But make no mistake — all of them are end-to-end to some degree.
They share the same goal: to validate that the system works for its real consumer, internal or external.
In this image, forget about system tests and component test, but focus on integration(e2e) and unit… this makes sense to me:
Conclusion
The test pyramid was a neat drawing for a simpler time.
Today, it’s a distraction.
Everything in real-world systems is end-to-end: the only question is whose end you’re testing.
A database, an API, or a user interface… they’re all clients in the same chain of truth.
Chasing geometric purity is meaningless.
What matters is the fidelity of your feedback loops and the confidence your tests give to your team.
Forget the pyramid.
Everything is E2E.