Trust As The Starting Point
Software development carries an implicit promise: the code we ship will work for the people using it. As developer Jan Philip Pietrczyk puts it, users trust us not only to do our best, but to deliver something that actually functions. Testing is the mechanism that honors that trust, validating work against real scenarios before flaws become failures.
Yet knowing what to test and how remains the persistent challenge. Kent C. Dodds frames it well: the goal is true confidence, not the false confidence that comes from testing implementation details. A testing strategy must therefore define its purpose first, then find the right balance of test types to achieve it.
The widely cited Test Pyramid has guided that balance since 2012, but its prominence has faded. Is it still the right model for today's development practices, or has it been superseded by approaches that better reflect how we build software now?
Refreshing The Test Vocabulary
Before evaluating strategies, it helps to align on what the different test types mean:
- Manual tests rely on human testers following scripted use cases and attempting unscripted scenarios to break the app, often observed by the product team.
- Unit tests break the application into small, isolated, testable parts, verifying each unit independently.
- Integration tests exercise the interaction between components or systems, checking that units work together as a coherent whole.
- End-to-end (E2E) tests simulate actual user interactions, validating complete user stories from input through to expected output.
Strategies often get described as shapes, with the Test Pyramid as the traditional go-to metaphor for how these types fit together.
The Test Pyramid In Practice
Introduced by Mike Cohn in Succeeding with Agile and elaborated by Martin Fowler in his later work on the practical test pyramid, the model prioritizes tests by cost and performance. The hierarchy runs from the bottom up: many fast, cheap, reliable unit tests, a smaller layer of service or integration tests in the middle, and a thin slice of UI or end-to-end tests at the top.
Criticism has grown that the pyramid oversimplifies test structure. Fowler himself revisited the shape nearly a decade later, acknowledging its limits. Teams increasingly question whether the model brings work closer to the end user or pushes it further away. While upper levels of the pyramid deliver more confidence per test, the shape feels less attentive to the broader picture of system behavior.
A Diamond-Shaped Alternative
One recurring complaint concerns the pyramid's over-emphasis on unit testing. The shape implies that unit tests should dominate the suite, but defining what counts as a unit test in the first place yields wildly different answers. Where does unit testing end and integration testing begin?
The diamond shape offers a different distribution:
In this model, the integration layer gets split into two distinct tiers:
- The Integration Test Layer handles tests too large to be unit tests, such as verifying a specific component in isolation.
- The System Integration Test Layer performs "real" integration tests, like validating data received from an external API.
The diamond still relies on unit tests, but they are written after integration testing rather than dominating the process. Integration testing, often called the "forgotten layer" because of its complexity, finally receives appropriate attention, while individual unit tests taper off in emphasis.
Manual Testing Deserves A Place
Both shapes share a common omission: manual testing does not appear anywhere in the layers. Automated tests are valuable, but they should not make manual practices obsolete.
Automation and manual testing work best in tandem. Routines and repetitive checks get delegated to automated tests, freeing human testers to focus on areas requiring judgment and observation. Manual testing remains essential for comprehensive coverage, even if automation carries the bulk of the workload in an ideal strategy.
That combination suggests a different shape entirely — an ice cream cone, with a broad base of E2E and manual tests stacked above thinner layers of integration and unit tests:
Known as the "Ice Cream Cone" approach, this strategy takes longer to implement but yields higher confidence and catches a greater number of bugs. Manual testing figures prominently at the wide base, supporting the layers built atop it.
Beyond The Cone
The exploration does not stop there. Gleb Bahmutov pushes the metaphor further with the "Testing Crab," a model centered on visual regression screening. Screenshot comparisons are verified by human review, placing visual and functional testing at the "body" of the crab while all other forms of testing act as supporting "limbs." Tools that layer before-and-after snapshots during tests can expose visual regressions that purely logic-based tests would miss.
Each shape — pyramid, diamond, cone, or crab — captures a different truth about where confidence comes from. The question of which strategy fits today's development is not about choosing the most popular shape, but about matching the model to the reality of how the software will be used and where failures are most likely to occur.
Rethinking The Test Pyramid's Shape
No testing strategy is free, and the Test Pyramid deserves credit for recognizing that trade-off. But its classic shape may not reflect where testing effort actually pays off. The real goal is a balance of test types that mirrors the value each layer provides. Guillermo Rauch summed this up neatly in 2016: “Write tests. Not too many. Mostly integration.”
- Write tests — they build confidence and reduce maintenance overhead.
- Not too many — 100% coverage is seductive, but it drags in tests that don't serve the end-user and adds maintenance burden for little return.
- Mostly integration — a higher volume of integration tests offers strong confidence with practical execution times.
Kent C. Dodds’ “Testing Trophy” model pushes this idea further. It reorders the layers of the pyramid, placing a greater emphasis on integration tests than the traditional model suggests.
The trophy concept classifies testing into four groups, each with a specific role:
- Static analysis: catches typos and type errors quickly.
- Unit tests: less important than in the pyramid's layout.
- Integration tests: the core of the strategy, offering real insight into product behavior.
- UI tests: E2E and visual checks still matter here, as in any model.
The trophy approach centers on user perspective and offers a solid cost-to-benefit ratio. Still, integration and E2E tests carry their own trade-offs — longer runtimes, lower reliability. Unit tests remain useful, and many teams find they still need them.
Can The Pyramid Still Earn Its Place?
The Test Pyramid is a long-standing reference, and its endurance isn't accidental. But it has limits, particularly when it comes to defining what a “unit test” actually is. That ambiguity often forces teams to adjust rather than adopt it wholesale.
On our own pipeline, we initially worked with a modified diamond shape. It wasn't incorrect — just incomplete. Even so, it offered a useful starting point for thinking about test distribution.
Rigid adherence to any test shape may be missing the point. Most teams don't follow textbook breakdowns anyway. As Justin Searls put it:
People love debating what percentage of which type of tests to write, but it's a distraction. Nearly zero teams write expressive tests that establish clear boundaries, run quickly & reliably, and only fail for useful reasons. Focus on that instead.
That speaks to a common experience: separating tests into clear, well-defined categories is genuinely difficult. Martin Fowler has noted that alternative testing models have contributed to the way we think about coverage. The pyramid isn't dead — knowing it still matters. The real priority is that tests run fast, behave reliably, and fail only when something meaningful goes wrong. The user's benefit, not coverage for its own sake, should steer the design.
