Carolina Ramirez’s comparison of software-testing strategies deserves credit for putting several influential models—the pyramid, honeycomb, trophy, and hourglass—into one accessible account. The underlying models also have identifiable creators and contexts: Mike Cohn introduced the test-automation pyramid; André Schaffer and Rickard Dybeck proposed the honeycomb for Spotify microservices; and Kent C. Dodds developed the testing trophy for frontend applications.
Seeing the diagrams together suggests a tempting question: which shape is correct? That is the wrong level of comparison. Each diagram compresses assumptions about architecture, failure cost, test speed, observability, and maintenance. A test strategy should recover those assumptions before copying the geometry.
The strategy is the allocation of verification effort against risk. The shape is only a summary produced afterwards.
Why the diagrams disagree
The classic pyramid recommends many small tests, fewer service-level tests, and a small number of expensive UI tests. Its economic argument remains useful: fast, localized feedback is cheap to run and easy to diagnose, while broad system tests are slower and often more fragile.
The honeycomb starts from a different system boundary. In Spotify’s microservice context, much of the meaningful complexity lived in interactions. Schaffer and Dybeck therefore emphasized integration tests around service edges, kept a smaller number of implementation-detail tests, and avoided tests dependent on live external systems where possible.
The trophy responds to frontend economics. Dodds argues that integration tests often provide a strong balance between confidence and cost, with static checks as a broad base and a smaller number of end-to-end tests for complete behaviour.
These positions are not mutually exclusive laws. They answer different questions about where defects hide and where useful observations can be made cheaply. If the unit boundary captures the important invariant, unit tests have high leverage. If risk emerges mainly at contracts, isolated unit coverage may be abundant yet unpersuasive. If the browser is the only place where several technologies and user-visible states meet, some end-to-end evidence is unavoidable.
Test labels hide several independent dimensions
Terms such as unit, integration, and end to end often mix unrelated properties:
- scope of behaviour;
- number of processes or components;
- use of real or substituted dependencies;
- distance from the user interface;
- execution time;
- diagnostic precision;
- ownership and environment stability.
An integration test can run in milliseconds against in-memory collaborators, or for minutes against shared infrastructure. A browser test can isolate one component or traverse an entire distributed workflow. A property-based unit test can explore a larger input domain than a single end-to-end example. Counting tests by label therefore gives little evidence about the portfolio.
A strategy should instead describe what each test proves, which failures it can expose, and what it costs to maintain and interpret.
Start with the failure model
For each important risk, ask five questions:
- Consequence: What happens if this behaviour is wrong?
- Fault location: Where could the responsible defect enter?
- Observation: What is the cheapest trustworthy oracle?
- Environment: Which real dependencies are necessary to expose the failure?
- Feedback: How quickly and precisely must the result reach the responsible engineer?
The answers usually produce a mixed portfolio:
| Risk | Useful evidence | Common limitation |
|---|---|---|
| Pure calculation is wrong | examples, properties, differential checks | reference or property can share the defect |
| Components disagree on a contract | schema and consumer-driven contract tests | deployed configuration may still differ |
| Persistence semantics are wrong | component test with a real database | production scale and migration history differ |
| User cannot complete a critical journey | bounded end-to-end test | slow diagnosis and environmental noise |
| System degrades under load | workload model and performance experiment | representativeness of traffic and infrastructure |
| Monitoring fails to detect harm | controlled fault injection | experiment scope and operational risk |
No single shape expresses all of these obligations. The portfolio can still have a visual profile, but it will be an empirical consequence of the system rather than a target ratio chosen in advance.
Allocate evidence, not test counts
A strategy based on percentages—70% unit, 20% integration, 10% end to end—invites the wrong optimization. Teams can satisfy it by creating many trivial unit tests while leaving a critical boundary unverified. Test count also treats a one-line example and a stateful generative model as equivalent units.
Better allocation questions include:
- Does every high-consequence failure have at least one credible detection mechanism?
- Is the oracle independent enough to detect implementation mistakes?
- Are important equivalence classes and state transitions represented?
- Can failures be reproduced and localized?
- Which tests block delivery, and is their signal reliable enough to justify that authority?
- Which evidence exists only in production, and how is it monitored?
- Which tests cost more to maintain than the risk they control?
This also changes how a suite is reviewed. A slow test is not automatically bad if it is the only credible observation of a critical workflow. A fast test is not automatically valuable if it checks an implementation detail that changes with every refactor.
A strategy must be allowed to change
Architecture, traffic, team ownership, and tooling evolve. A portfolio that was rational for a monolith may become misleading after decomposition into services. A browser suite may become cheaper after improved tracing and isolation. A once-stable external dependency may require contract monitoring. Production incidents may reveal an untested class of state transitions.
The strategy should therefore preserve its reasons. When a test is added, moved, or deleted, the team should be able to say which risk and evidence relationship changed. Diagrams can help communicate the current portfolio, but they should not freeze an old economic model into policy.
Ramirez’s comparison is valuable as a map of testing ideas. The next step is to read each model as a contextual argument rather than a universal template. Choose test boundaries from the cheapest credible oracle for each important risk, then inspect the resulting portfolio. If it resembles a pyramid, trophy, honeycomb, or none of them, that is a secondary fact. The primary question is whether the evidence supports the release decisions the organization intends to make.