Test Levels and the Test Pyramid Questions

Refactoring a legacy UI changes which test level is actually trustworthy: the code you're about to rewrite is exactly the code your existing tests were written against, so the SAME test that normally gives confidence can instead actively mislead you if it's coupled to implementation details rather than to observable behavior.

Comparing the three levels for a refactor specifically

• Unit tests: cheapest to run and fastest to give feedback, with the lowest flakiness risk of the three since they involve no real I/O, network, or rendering timing, but the ones most likely to be coupled to the OLD implementation's internal structure (specific component boundaries, internal state shape) rather than to genuinely observable behavior; a refactor that changes internal structure without changing behavior will break many of these even though nothing is actually wrong, producing false-negative noise exactly when you need signal most. That noise is a maintenance-cost problem, rewriting tests against the new structure, not a flakiness problem: a red unit test during a refactor is almost never a flake.
• Integration tests: a better middle ground for a refactor, since they typically assert on a slightly higher-level contract (does this component correctly call the API and update in response) that survives internal restructuring better than a narrow unit test does, while still being far cheaper and more precise than a full end-to-end test; flakiness risk sits between the other two levels, since touching one real dependency (a test server, a real local store) introduces some timing variance, but far less than a fully rendered UI does.
• End-to-end tests: the most trustworthy signal during a UI refactor specifically, because they assert on OBSERVABLE USER-FACING BEHAVIOR (does the page still do what a user needs it to do) rather than on any internal structure, so they are largely immune to being broken by the refactor itself; the cost is that they're slow, imprecise about WHERE a real regression is if one occurs, and the flakiest of the three, since real rendering, animation, and network timing introduce genuine non-determinism. During a refactor specifically that means a red end-to-end test needs a first pass to rule out an ordinary flake, by rerunning it, before you treat it as the trustworthy signal the rest of this comparison relies on it being.

Prioritizing which to write first during a large refactor

Write a small set of end-to-end tests FIRST, covering the critical user journeys the section being refactored supports, as a behavior-preserving safety net: these tests should pass before, during, and after the refactor, since they check outward behavior the refactor is not supposed to change. Only after that safety net exists should new unit and integration tests be introduced for the NEW internal structure, written against the refactored code's actual new boundaries, since writing them against the OLD structure just before deleting that structure would be wasted effort.

A test pyramid for a typical medium-sized frontend application

Once the refactor is complete and normal development resumes, return to a standard frontend shape: a large base of unit tests for pure logic and isolated component behavior, a solid middle layer of component-level integration tests (rendering a component with React Testing Library or similar, confirming it correctly calls its collaborators and updates state), and a small, curated top layer of full end-to-end tests for the handful of critical journeys, mirroring the same shape recommended for other frontend contexts, with the refactor-specific end-to-end safety net folded back into that small curated top layer rather than kept as a separate, larger set.

Trade-offs and pitfalls

The pitfall specific to a refactor is treating a failing unit test during the refactor as evidence something is broken, when it may simply be evidence the test was coupled to implementation details that were always going to change; before "fixing" such a test, first confirm via the end-to-end safety net whether user-facing behavior actually changed, and if it did not, the right fix is usually to rewrite the unit test against the new structure, not to change the refactored code to satisfy the old test.

The test pyramid is a shape you aim for when deciding how many tests to write at each level: many fast, narrow unit tests at the base, a smaller number of integration tests in the middle, and very few, broad end-to-end tests at the top. The core claim is not "unit tests are better," it is that the ratio should be inverted from what a naive test-writer defaults to: most bugs are logic bugs that a unit test finds cheaply, so you want the bulk of your assertions living where they are cheap to write, fast to run, and precise about what broke, and you reserve the slow, broad, more failure-prone end-to-end tests for the small number of things only they can prove: that the assembled system, wired together for real, actually works.

The tiers

• Unit: a function or class tested alone, dependencies faked. Goal: prove the logic is correct, in isolation, in milliseconds.
• Integration: your code against one real neighbor (a database, a queue, one real service). Goal: prove the wiring and serialization between two real things is correct.
• End-to-end: the system driven through its real entry point, nothing faked. Goal: prove the whole thing actually delivers the right behavior to a real caller.

Why more low-level tests than high-level

Three forces push the shape into a pyramid rather than a rectangle or its inverse:

1. Cost. An end-to-end test typically needs a running environment, real data, and real network calls; a unit test needs none of that. If a unit test costs 1 unit of setup and run time, an integration test might cost 10-50x that, and an end-to-end test 100-1000x that, so a rectangle-shaped suite (equal counts at every level) would make your CI/CD pipeline unusably slow and destroy the fast feedback a pipeline exists to provide.
2. Feedback precision. When a unit test fails, you already know which function is wrong. When an end-to-end test fails, you know the system as a whole is broken but not where, and diagnosing that costs real engineering time.
3. Flakiness. The more real infrastructure a test touches (network, clock, shared state), the more opportunities it has to fail for reasons unrelated to the code under test. A large end-to-end suite tends to accumulate intermittent failures that erode trust in the whole pipeline.

Worked example (web application)

For a typical web application: unit tests for pure helper functions (a discount calculator, a date formatter), commonly written with a plain test runner like pytest or Jest; integration tests for the API-to-database path (does saving an order actually persist the right row?), commonly using an HTTP-assertion library such as Supertest against a real test database; end-to-end tests for a checkout flow driven through the real UI or a real HTTP client, confirming a user can go from "add to cart" to "order confirmed," commonly using a browser-automation tool such as Playwright or Cypress. A healthy team might run thousands of unit tests in under a minute, a few hundred integration tests in several minutes, and a few dozen end-to-end tests in tens of minutes, matching the pyramid's shape to the cost curve above.

Trade-offs and limitations of the model

The pyramid assumes most defect risk lives in logic that a unit test can isolate. That assumption weakens for systems whose main risk is integration itself, such as a thin orchestration layer that mostly calls other services and has little logic of its own: here, integration and contract tests carry more of the confidence burden, and a strict pyramid ratio would under-test the actual risk. This is the same observation that motivates alternative shapes like the testing trophy (an alternative shape that keeps a small unit-test base but makes integration tests the largest layer, on the idea that tests resembling real usage give more confidence), which is worth naming as a caveat even in a definitional answer: the pyramid is a strong default, not a law. The common pitfall in applying it is treating the shape as a hard quota (chasing a specific unit-test count) rather than as a description of where investment should land once you've correctly identified where a given system's real risk lives.

With limited CI minutes, the right rule is: run what's cheap enough to not slow anyone down on every commit, defer what's expensive but low-risk-of-being-wrong-right-now to nightly, and gate what's slow but release-critical to the release pipeline.

What runs where, by level

• Every commit / pull request: the full unit-test suite (should be fast enough, seconds to low minutes, that nobody thinks twice about running it) plus a small, curated smoke set of the highest-value integration and end-to-end tests covering your one or two most critical journeys (login, checkout). Rationale: a developer needs fast feedback on the logic they just touched, and a small smoke layer catches the worst wiring regressions before they even reach a shared branch.
• Nightly: the full integration suite and the full end-to-end suite, run against a shared or staging-like environment. Rationale: these are too slow to run on every commit without destroying developer velocity, but running them nightly still catches integration regressions within a day, which is an acceptable latency for bugs that are rarer than pure logic bugs.
• Pre-release / release gate: a final full end-to-end pass plus any slow, environment-heavy tests (performance baselines, cross-browser matrices) that are too expensive to run even nightly. Rationale: this is the last checkpoint before real users are affected, so it's worth paying maximum test cost here even though it's not worth paying it on every commit.

A proposed ratio and CI-time budget for a typical SaaS application

A reasonable starting ratio is roughly 70% unit, 20% integration, 10% end-to-end by test count, with a target CI-time budget per layer on a pull request of: unit tests under 2 minutes total, the curated smoke slice of integration/end-to-end tests under 5 minutes total, so the whole PR check stays under about 7 minutes, comfortably inside the roughly ten-minute mark where most teams report developers start context-switching away and waiting on results loses its value.

Tactics to enforce those CI-time targets without silently losing coverage

• A fast smoke suite: a small, deliberately hand-picked subset of integration/end-to-end tests covering your highest-risk journeys, run on every PR instead of the full suite, so PR feedback stays fast while still catching the worst regressions immediately.
• Test selection: running only the tests whose code path plausibly touches the files changed in a given commit, rather than the entire suite, to cut PR time without reducing what eventually gets run before release.
• Test-impact analysis: a more precise, automated version of test selection that uses a dependency map (which tests exercise which source files, including transitive dependencies) to compute the minimal correct test set for a given diff, rather than relying on manual tagging.

Applied together, these tactics let a team keep the FULL suite's coverage intact (nothing is deleted, nothing stops running entirely) while making sure only the necessary fraction of it runs on the expensive, time-constrained PR path.

Trade-offs and pitfalls

The common failure mode is letting the "nightly" bucket become a dumping ground: tests get moved there because they're slow or flaky, not because nightly is genuinely the right cadence for their risk level, and regressions caught only nightly then sit unnoticed for a full day while more commits pile on top, making the eventual fix harder to isolate. Treat the nightly tier as a deliberate risk-and-cost decision per test, not a place to hide problems.

A test suite should contain far more unit tests than end-to-end tests because the two levels trade off cost against realism in opposite directions, and the cheap-and-precise end of that trade dominates for the vast majority of the bugs you actually need to catch.

Five reasons, each with a concrete illustration

1. Cost of running. A unit test for a pure function runs in well under a millisecond and needs no external process. An end-to-end test for the same behavior needs a running server, a database, and often a browser or HTTP client, and commonly takes seconds. Run a suite of 2,000 tests: at unit-test speed that finishes in well under a minute; at end-to-end speed the same count could take hours, which no team can afford to run on every commit.
2. Feedback speed. A developer who breaks a function wants to know within seconds, while still holding the change in their head. A unit test gives that immediately; an end-to-end test, queued behind environment provisioning and a full pipeline run, might report the failure twenty minutes later, by which point the developer has moved on to something else and the context-switch cost to fix it is much higher.
3. Maintainability. A unit test breaks only when the specific function's contract changes. An end-to-end test walks through many screens or endpoints, so it is coupled to all of them at once: a single unrelated UI change (a renamed button, a reordered field) can break dozens of end-to-end tests that were never testing that button in the first place, creating maintenance work with zero corresponding increase in confidence.
4. Diagnostic precision (technical). When a unit test fails, the failure message names the exact function and assertion that broke. When an end-to-end test fails, you know only that somewhere across dozens of components something is wrong, and someone has to spend real time narrowing that down, effectively re-deriving the information a unit test would have handed you directly.
5. Organizational scaling. As a codebase and team grow, the number of possible logic paths grows roughly with the code, while the number of realistic whole-system journeys grows much more slowly (most new logic is a variation inside an existing journey, not a brand-new one). Unit tests scale naturally with that logic growth; trying to scale end-to-end tests at the same rate produces a suite that is mostly redundant coverage of the same few journeys, wasting CI time without adding proportional confidence.

Trade-offs and pitfalls

None of this means end-to-end tests are dispensable: they are the only level that proves the pieces are actually wired together correctly for a real user, which is exactly the class of bug the other four reasons cannot catch. The pitfall is treating "more unit tests" as license to skip end-to-end coverage of your critical paths entirely; the healthy pattern is a small, curated set of end-to-end tests covering the handful of journeys that matter most (checkout, login), backed by a much larger base of fast unit tests covering the underlying logic.

The classical test pyramid says most tests should be unit tests, fewer should be integration tests, and very few should be end-to-end tests, on the assumption that most risk lives in isolated logic. The testing trophy (associated with Kent C. Dodds) inverts that emphasis for a different class of system: it keeps a small unit-test base, but makes integration tests the LARGEST layer, on the argument that "the more your tests resemble how the software is actually used, the more confidence they give you," and a pure unit test that mocks everything often resembles real usage the least. A related shape, sometimes called the honeycomb (associated with Spotify's microservices testing writeup), similarly shrinks the unit layer and grows the middle layer specifically for service-heavy backends, on the reasoning that a small microservice's real complexity is almost entirely in how it talks to its neighbors, not in isolated internal logic.

The trade-off between the models

Both alternative models trade some unit-test speed and precision for tests that more closely resemble real usage and therefore catch a class of bug (real interaction failures) that heavily-mocked unit tests structurally cannot. The cost is that integration-heavy tests are slower and can be harder to debug when they fail, since a failure could originate in either side of the interaction being tested, and you lose some of the pure pyramid's clean bug-to-test correlation.

Three scenarios where deviating from a strict pyramid makes sense

1. A frontend component library where the real risk is composition, not isolated logic. Testing individual components in isolation with heavily mocked props tells you little about whether they actually work together on a real page; integration-style tests that render a realistic tree of components and simulate real user interaction (the trophy's core argument) catch the bugs that matter, at some cost in speed. Risk: slower test runs and less precise failure localization. Mitigation: still keep a lean unit-test layer for pure logic (formatters, validators) where isolation genuinely helps, and reserve the larger integration layer for component composition specifically.
2. A small microservice whose logic is thin and whose risk is almost entirely in its contracts with neighbors. A strict pyramid would still demand a large unit-test base even though there is little logic to test in isolation, wasting effort; a honeycomb shape that invests more heavily in contract and integration tests reflects where the actual risk sits. Risk: contract drift between services can slip through if the integration/contract layer isn't kept current with real provider behavior. Mitigation: pair the heavier integration layer with automated, CI-enforced contract verification rather than hand-maintained fixtures.
3. A legacy system with tangled, hard-to-unit-test code and existing integration coverage. Rewriting for unit-testability before adding any coverage at all can take months, during which the system ships with no safety net; leaning temporarily on integration or characterization tests around the existing behavior gives real protection sooner. Risk: those tests are slower and give less precise failure information, becoming a long-term crutch if never followed by proper unit-level refactoring. Mitigation: treat the integration-heavy phase as explicitly temporary, with a tracked follow-up plan to extract unit-testable logic once coverage exists to refactor safely.

Trade-offs and pitfalls

The risk in adopting either alternative model is doing so out of preference rather than evidence: the trophy and honeycomb are correct responses to specific risk profiles (interaction-heavy frontends, thin microservices), not universal replacements for the pyramid. Applying a trophy shape to a computation-heavy backend service, where the real risk genuinely is isolated logic, would slow the suite down for no corresponding gain in the bugs it catches.