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, which is what everyone tells you to do. 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. Two of them you will read everywhere. The third is the one that matters most and is usually left out.
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 is the one to remember, and it is the strongest argument of the three.
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 the shape most real suites actually have. A wide layer of end to end tests on top, almost nothing underneath. Martin Fowler calls it the ice cream cone.
Nobody chooses this. Teams arrive at it 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 reasons nobody trusts, and the first thing to die is the habit of reading it.
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
Here is the part that gets left out of most articles about this.
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 of the two lower levels deserves the most weight, and the honest answer depends on what you are building.
Take the pyramid as a warning about the top, not a rule about the bottom. Nobody who has run a large suite argues for more end to end tests.
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 handful of end to end tests that cover the paths that matter is worth more than 200 that cover everything and are trusted by nobody.
What an interviewer is really asking
This comes up constantly, and the question is never "can you name the three levels".
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.
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.