Testing by Return on Investment
Most developers are familiar with the testing pyramid, which suggests a broad base of unit tests supported by fewer integration tests and a small number of end-to-end tests. The Testing Trophy reimagines that structure specifically for JavaScript applications, shifting more weight toward integration tests while keeping static analysis tools in the mix.
The trophy model emerged from a practical need: determining where automated testing efforts deliver the most confidence for the effort invested. Unlike the pyramid, it includes static type checking and linting as a layer of protection, since those tools are not guaranteed in the JavaScript ecosystem the way they are in many statically typed languages.
Where the Categories Came From
The definitions that shape the Testing Trophy grew out of front-end engineering experience, particularly work with code that runs in the browser. Two distinctions matter: a unit test exercises a single function, class, or object whose dependencies are either absent or mocked, while an integration test exercises multiple units working together. End-to-end tests are those that validate behavior with as little mocking as possible, ideally none at all.
These definitions deliberately avoid universality. Attempting to settle on a single definition for testing terms is an exercise in futility; the historical record shows wide disagreement. Martin Fowler's writing on test shapes notes that a "test expert" from the 1990s claimed to cover 24 different definitions of unit test in the first morning of a training course. The practical response is not to fight for one canonical taxonomy, but to choose labels that make sense for your context and your team, then move on to the actual work of building confidence.
The Rise of Testing Library
The classifications proved useful enough to become the foundation for Testing Library, which was created to encourage the practices that worked best in real projects. Testing Library is flexible across the categories: it can test individual React components in isolation, entire pages with HTTP requests mocked via MSW, full applications with minimal mocking, and individual React hooks if needed. By May 2020, Testing Library had earned the "Adopt" distinction on the ThoughtWorks Technology Radar and had become the de facto standard for testing in React applications.
The effective use of Testing Library typically results in what looks like a trophy shape in practice: fewer unit tests, a heavy middle section of integration tests, and a small number of end-to-end tests for the most critical user journeys.
Classification Is Less Important Than Practice
The debate over terminology and the ideal proportion of each test type misses the point. As one widely shared observation puts it, nearly no teams write expressive tests that establish clear boundaries, run quickly and reliably, and only fail for useful reasons. The conversation about test ratios is a distraction from that far more valuable goal.
Tim Bray frames the broader issue well when he notes that software-testing tenets should not be mistaken for scientific knowledge. Even the question of whether testing is effective does not have a settled empirical answer, and much of the disagreement among practitioners comes down to definitions rather than actual testing strategy. Discussions about the Testing Pyramid versus newer shapes will continue, but the underlying question that matters is whether your tests give you the confidence to ship changes without breaking what already works. If they do, the exact labels on the categories matter very little.
Where the Trophy Fits
The testing trophy is best understood within a single codebase, not across a distributed system. It applies to backend code as readily as frontend, but only in a monolith context. Microservices and serverless functions don’t map cleanly onto the model — and, as Tim Bray has argued, most teams should be building monoliths anyway if they can.
Read correctly, the trophy gives a clear sense of where testing effort pays off. The guiding principle underneath it comes from Kent C. Dodds:
The more your tests resemble the way your software is used, the more confidence they can give you.
That idea is the foundation of Testing Library and the lens through which every testing problem is best considered. It keeps the real objective in view: confidence as the return, time as the investment. If time were unlimited, classification wouldn’t matter — you’d simply test everything endlessly. Since it isn’t, a framework for prioritizing effort is what the trophy actually provides.
Further Reading
- Confidently Shipping Code explains why testing matters at all.
- Static vs Unit vs Integration vs E2E Testing for Frontend Apps digs into what each test class means — and why the distinctions sometimes don’t matter. Includes concrete code examples.
- Testing Implementation Details covers why testing how code is written rather than what it does leads to fragile suites.
- Avoid the Test User explains how UI code has two real users, but badly designed tests can introduce a third.
- Should I write a test or fix a bug offers guidance on prioritizing tests alongside other work.
- How to know what to test gives practical direction on choosing test targets.
