Testing Strategy for a Large React Codebase
A client's React codebase we inherited had around 2,000 unit tests, mostly shallow-rendered component tests checking that specific props produced specific output, and the team was still shipping user-facing regressions on a near-weekly basis. The tests were passing and the app was still breaking, which told us the problem wasn't test coverage as a raw number — it was that the tests were concentrated at a layer that didn't catch the bugs actually reaching users.
Most of the regressions were integration failures — a form submission that worked in isolation but broke when combined with a specific validation state, or a page that rendered fine with mock data but failed against the real API's actual response shape. We shifted the testing investment toward React Testing Library tests that render full user flows against a mocked API layer using MSW, testing what a user actually does — fill in a field, click submit, see a confirmation — rather than what a component's props produce in isolation.
We didn't throw out unit tests entirely; they're still the right tool for pure functions and utilities where isolated behavior is exactly what you want to verify, like a pricing calculation or a date formatter. What we cut back sharply was shallow component tests that mock every child component and assert on rendered prop values, which tended to break on harmless refactors and pass right through actual integration bugs.
End-to-end tests with Playwright cover the handful of flows where a real regression is expensive — checkout, account creation, the core dashboard load. We deliberately kept this suite small, around 25 tests, because E2E tests are slow and flaky at scale, and a bloated E2E suite becomes something the team learns to ignore when it fails, which defeats its purpose entirely.
Eight months after rebalancing the test pyramid — fewer shallow unit tests, more integration tests, a small focused E2E suite — user-facing regressions reported in production dropped by roughly 70% based on the client's own bug tracker, even though total test count actually went down. The number of tests was never the metric that mattered; what mattered was whether the tests exercised the same paths users actually take.
