The Testing Trophy: Prioritize Integration Tests

Why it exists

Classic testing models like the Testing Pyramid didn't perfectly map to the realities of modern UI development. In component-based apps, many bugs aren't in a single function's logic but in the seams between components. A new mental model was needed to reflect the high return on investment from testing these interactions.

The mental model

The Testing Trophy is a visual guide for test distribution, shaped by ROI. Imagine a trophy: a wide middle section (Integration Tests), a smaller base (Unit Tests), and a small top (End-to-End Tests), all standing on a large platter (Static Analysis). This shape emphasizes that the bulk of your effort should be on integration tests because they provide high confidence at a reasonable cost.

How it works

The trophy categorizes tests by scope and purpose. Static analysis (like TypeScript or ESLint) forms the foundation, catching errors before runtime. Unit tests verify the smallest pieces of logic, like a single function, in isolation. Integration tests, the core of the trophy, check that several units work together as expected—for example, a form component with its input fields and a button. End-to-end (E2E) tests sit at the top, automating a real user journey through the entire application. The trophy advises writing a lot of integration tests, fewer unit and E2E tests, and relying heavily on static analysis.

When to use it

This model is ideal for JavaScript applications, especially those built with component-based frameworks like React, Vue, or Angular. Use it when you want to write tests that are resilient to refactoring and provide strong confidence that your application works for users. It's the philosophy behind popular tools like Testing Library.

When not to use it

The Testing Trophy is explicitly framed for UI applications. While the principle of ROI is universal, the specific distribution might not apply to backend services or libraries with complex, isolated algorithms. For those, a more traditional testing pyramid with a larger base of unit tests might be more appropriate. Don't treat the trophy's shape as a dogmatic rule for every project.

One canonical example

Consider a login form component. A unit test might check that the email validation function works correctly. An E2E test would launch the app and simulate a full login. The Testing Trophy's sweet spot, the integration test, would render the entire form component, simulate a user typing into the fields, click submit, and assert that the correct API call was attempted. This tests the collaboration of all the form's parts without the slowness of a full E2E test.