The test pyramid isn't a diagram, it's a cost decision

When someone new joins a quality team, they've almost always already seen the test pyramid somewhere: a triangle with "unit" at the bottom, "integration" in the middle, and "E2E" at the top. Most people treat it like a poster. I treat it like a cost sheet.

Each layer of that pyramid has a different price — not just in execution time, but in how much breaks when the code changes. Tap each layer:

Why the width matters

The width of each layer isn't aesthetic. It represents how much testing you should have there, and that proportion comes directly from fragility:

• A unit test only fails when the logic it tests changed. It runs in milliseconds. You can have thousands.
• An integration test fails when the contract between two modules changes — more signal, but also more cost to keep it alive.
• An E2E test fails because of almost anything: a UI selector that moved, a network timeout, test data another test already modified. It gives the most confidence and costs the most to maintain.

A concrete case

Here's what the difference between checking only the status code and checking the full contract looks like, in an API framework built on Postman:

pm.test("status 200", () => {
  pm.response.to.have.status(200);
});
// Passes even if the response comes back empty, mistyped,
// or with a renamed field. It doesn't test the real contract.

The second test is an integration test, not an E2E — it runs in seconds, not minutes, and fails for the right reason: the contract changed, not because a button moved three pixels.

The question that replaces the poster

Next time someone proposes "let's add an E2E test for this," the useful question isn't whether the case matters. It almost always does. The question is: does this need to confirm the whole system works together, or is it enough to confirm this piece meets its contract? Most of the time, the second is enough — and it's cheaper to keep alive.