Your suite has 200 end-to-end tests. A full run takes forty minutes. Last week it went red three times, and all three times the test was wrong, not the application. So people stopped reading the result.
Nobody on that team was careless. They wrote tests that check real user journeys. They just wrote almost all of them at the slowest and least stable level.
The pyramid above is the idea that fixes this. Turn it, then read on.
What the shape is saying
Mike Cohn made this popular in his 2009 book Succeeding with Agile, where he called it the test automation pyramid.
The width of each level is how many tests belong at it. Many at the bottom, fewer in the middle, a few at the top. That is the whole diagram. Everything else is the reasoning.
The three levels, in plain terms:
- A unit test checks one piece of code on its own, with everything around it faked. It answers "is this function correct".
- An integration test checks that several pieces still work once they are joined together. It answers "do these parts fit".
- An end-to-end test drives the real application the way a person would, through the interface. It answers "can someone actually complete this journey".
Why the shape leans that way
Three reasons explain the shape. The third is easy to overlook.
Speed
A unit test runs in milliseconds. An end-to-end test runs in seconds or minutes, because it starts a browser, loads a page, waits for the network, and clicks through screens.
Multiply that by a suite. A thousand unit tests can finish before one page has loaded.
Cost to keep
An end-to-end test touches everything, so anything can break it. A renamed button, a slower server, a changed date format. Each break costs somebody an afternoon, and that cost repeats forever.
How precisely a failure points at the cause
This reason also explains why some failed tests take longer to diagnose.
When a unit test fails, you know which function is wrong. The test only touched one thing, so there is only one place to look.
When an end-to-end test fails, you know that "checkout is broken". The cause could be the button, the form, the API, the database, the network, the test data, or the test itself. You have a symptom, not a location.
A failing test is a question, and the level decides how narrow the question is. A unit test asks something small and hands you an answer. An end-to-end test asks something huge, so a red result is the start of an investigation rather than the end of one.
That is why you want many narrow tests and few wide ones. Not because wide tests are bad, but because a suite made of them tells you that something is wrong without telling you what.
The ice cream cone
Turn the pyramid upside down and you get an unhealthy shape. It has a wide layer of end-to-end tests on top and almost nothing underneath. Martin Fowler calls it the ice cream cone.
Teams can arrive at this shape one reasonable decision at a time:
- The application already exists and has no unit tests. Adding them means changing the code. Adding an end-to-end test means changing nothing, so that is what gets written.
- A bug reaches production. Someone asks for a test "that catches it the way a user would", and an end-to-end test is the obvious answer.
- Testing belongs to one person rather than the team, and the only tests they can write without a developer are the ones that go through the interface.
Every step is sensible on its own. The result is a forty minute suite that fails for unclear reasons. The team may stop trusting and reading the results.
The fix is slow and boring, and it is not a rewrite. When a bug is found, write the lowest level test that would have caught it. Over a few months the shape corrects itself from the bottom.
It is a heuristic, not a law
The pyramid is a guide, not a fixed rule.
The pyramid was drawn when a unit test was cheap and an integration test meant standing up a server and a database. Front end work changed that balance. Running a component with its real neighbours is now fast and easy.
Kent C. Dodds proposed a different shape called the testing trophy, building on a line from Guillermo Rauch: "Write tests. Not too many. Mostly integration." It puts integration tests at the widest point, with unit tests below and static checks like types and linting at the base.
The argument is worth understanding. A unit test of a user interface component that fakes everything around it can pass while the real screen is broken, because everything it might have caught was replaced with a fake. Dodds sums up the principle this way: "The more your tests resemble the way your software is used, the more confidence they can give you."
Notice that the two models agree far more than they disagree. Both say to keep end-to-end tests few. Both say most of your effort belongs below the interface. They differ on which lower level deserves more weight. That choice depends on what you are building.
Take the pyramid as a warning about the top, not a rule about the bottom. Too many end-to-end tests make a suite slower and harder to diagnose.
Where end-to-end tests genuinely earn their cost
Few is not zero, and the pyramid is often quoted as though it were.
Some things only an end-to-end test can tell you:
- The two or three journeys that make money. Signing up, paying, checking out. If one breaks, nothing else matters.
- Anything that crosses systems. Payment providers, single sign on, third party widgets. The seams between systems are exactly where unit tests cannot see.
- The paths where a failure is silent. A broken button shouts. A form that submits and quietly saves nothing does not.
That is a short list on purpose. A few end-to-end tests can cover the paths that matter. They are more useful than 200 tests the team does not trust.
What an interviewer is really asking
An interviewer may ask you to name the three levels. A stronger answer explains where a test belongs.
They want to know whether you can decide where a given test belongs and defend it. So answer with the reasoning, not the diagram. Something like: this is a pricing rule with many cases, so it belongs in unit tests where each case costs nothing. This is checkout, so one end-to-end test earns its keep because a silent failure there costs real money.
Say that and you sound like someone who has maintained a suite. Recite the shape and you sound like someone who has read about one.
Remember this
The width of each level is how many tests belong there. It leans that way because low tests are fast, cheap to keep, and above all precise about what broke. The upside down version is what teams drift into by accident, and it is fixed slowly from the bottom rather than by a rewrite. Treat the shape as a warning about the top, keep a few end-to-end tests on the journeys that matter, and be ready to say why a test belongs where you put it.
The pyramid tells you how many tests to write at each level. It does not tell you whether they work. You can find that out in the graded practice: every test you write there runs against the working app, then against a copy with the behaviour broken.
Next: how to fix flaky tests covers what to do when the tests at the top misbehave, and running tests in CI covers how to keep a suite fast once it grows.
Reference: Martin Fowler on the test pyramid.