The testing pyramid: why not everything should be E2E

The short answer is this: not everything should be E2E because a balanced suite has many fast unit tests, some integration tests and very few end to end ones. That proportion, and no other, is what makes a suite run in seconds, fail with precision and earn your trust. When you invert it, you get the opposite: hours of waiting and results nobody believes in.

Almost every team that struggles with its tests has the same structural problem, even if they do not know it. It is not that they are short on tests. It is that they have them in the wrong proportions. They have built the pyramid upside down.

01 · the shapeWhat the pyramid says and why it is a pyramid

The testing pyramid is an idea popularized by Mike Cohn that the industry adopted because it captures a real tension well. At the base sit unit tests: many, small, verifying a single function or class in isolation. In the middle, integration tests: fewer, checking that two or more pieces talk to each other correctly (your code and the database, your service and an API). At the peak, the E2E (end to end) tests: very few, exercising the full system the way a user would, from the click to the response.

The shape is not decorative. It is a pyramid because the proportions matter: plenty of the cheap and fast, little of the expensive and slow. Every level you climb, tests become slower to run, harder to write, more fragile in the face of any change and vaguer when they fail. A unit test that breaks points you to the exact line. An E2E test that breaks tells you that "something, somewhere, went wrong".

Every level you climb costs more and tells you less.

02 · the ice cream coneThe anti-pattern: when the pyramid gets inverted

Now flip the figure over. A narrow base of unit tests, a bit of integration, and on top a wide mountain of E2E. That has a name: the ice cream cone. It is the most common anti-pattern and almost never a conscious decision; you get there by accumulation.

It happens like this. The team is in a hurry. Writing an E2E test "feels" more complete: it opens the browser, clicks, checks that the screen shows the right thing. It seems to cover everything at once, so many get written and the unit tests get neglected. On top of all that there is usually a layer of manual tests done by people, the slowest and most expensive of all.

The result you feel firsthand:

• The suite takes hours. Every E2E boots the entire system. Hundreds of them turn validation into a long coffee break, not a short one.
• The tests are flaky. They fail and pass without you changing anything, because of a slow network, a timeout, an element that was slow to load. Flakiness is the poison of trust.
• Nobody trusts the red. When half the failures are noise, the team learns to ignore the red. And a suite that gets ignored protects you from nothing.
• When something fails, you do not know where. A broken E2E spans twenty components. Debugging it is a hunt, not a read.

03 · the proportionsHow much of each: a rule of thumb

There is no sacred table, but there is a useful order of magnitude that many teams use as a starting point: roughly 70 % unit, 20 % integration and 10 % E2E. Do not take it as law; take it as a compass. A very visual component may need more E2E; a calculation library needs almost only unit tests. What does not change is the hierarchy: the base always weighs more than the peak.

The right question when writing a test is not "which level do I use?", but "what is the lowest level that can give me this confidence?". If a bug can be caught with a unit test, catch it with a unit test. Reserve E2E for what only can be verified end to end: that the pieces, together and in a real environment, fulfill the critical user flow.

Think of it as a budget. Your suite spends CI time on every run, and that time is money and, above all, it is your team's speed. Every minute a person waits for a result is a minute without deploying. Unit tests buy a lot of confidence for very little time. E2E tests buy little confidence for a lot of time. A good QA manages that budget with the same discipline you would manage money: invest in the cheap and use the expensive with judgment.

Use the lowest level that gives you the confidence you are after. Not one level higher.

Fixing the ice cream cone is not throwing the E2E tests in the trash. It is the reverse: it is pushing validations down to the cheapest possible level and leaving on top only the handful of flows that truly matter. The suite slims down where it should and fills out where it counts. The day your CI runs in minutes again and the red means something again, you know the pyramid is standing on its base once more.

04 · the standardWhy this is also a quality decision, not just a speed one

It might look like all of this is about going fast. It is about something bigger. The ISO/IEC 25010 standard defines software quality in attributes such as reliability and maintainability. A balanced suite serves both directly: it is reliable because its red is signal and not noise, and it is maintainable because when something breaks, it leads you to the cause rather than to a hunt.

The ISTQB, in its body of knowledge for testers, insists that testing is an activity of risk management, not of accumulation. It is not about having more tests, but the tests that reduce the risk that truly worries you, at the lowest cost. The pyramid is, at bottom, that idea made shape: put the effort where it buys the most certainty for the least time.

So next time someone proposes "let us cover this with another E2E test", ask the usual question: is this the lowest level that gives us the confidence we are after? If the answer is no, you have a unit test waiting to be written, and a pyramid that will be grateful to stay standing.