I agree with the author that precise terminology matters, calling something “unit testing” when it isn’t can definitely blur discussions.

That said, I think the underlying issue isn’t Testing Library itself, but the broader reality that testability in React is inherently limited by its design. As J. B. Rainsberger put it: "If it’s hard to test your code, it’s a sign of a design problem." In my experience, this is one of the most reliable heuristics for evaluating a framework or library.

When I look at a new technology, testability is the very first thing I evaluate, by far the most important property. I don’t care much about performance, bundle size, or reactivity models if the code is hard to test. If it is, I’ll reject it immediately. Hard-to-test systems tend to accumulate complexity quickly, and over time that translates directly into slower iteration, more regressions, and less confidence in changes.

For context, I’ve been working as a software engineer for 15+ years, mostly on medium to large frontend codebases, and using React since around 2014. A large portion of my day-to-day work is writing and maintaining unit tests. Many of the projects I’ve worked on have test suites in the five-figure range that run in under 10 seconds (using fairly simple tooling like Mocha). With that setup, we’ve been able to sustain very high deployment frequencies (10–100 deploys per day), even to the point of auto-merging dependency updates on weekends with automatic deployment, without introducing regressions over long periods of time.

That’s why I’m fairly skeptical when people claim unit testing is overkill or doesn’t add value. In well-designed systems, it’s the opposite: strong unit testability is what enables speed and safety at scale. Integration tests still have their place, but mostly to cover happy paths and verify wiring, not to compensate for missing unit-level confidence.

Coming back to React: compared to other modern frontend frameworks, it’s arguably still in the best position for unit testing, but that’s a very low bar. Vue and Svelte typically require compilation steps and framework-specific tooling, and others like Solid often rely on a real DOM as well. The deprecated react-test-renderer at least allowed some level of isolation, but its developer experience was poor enough that it never became a great solution.

What bothers me more is the official push toward testing in a real DOM environment. Many React components are not even meant to run in a browser DOM in production, think of server components, React Native, react-three-fiber, or Ink. If the framework’s value proposition is to abstract away the runtime environment, then requiring developers to reintroduce that environment in tests feels like a step backwards.

More broadly, this seems to reflect a shift in priorities. Modern frameworks often optimize for advanced capabilities, things like page transitions, complex rendering patterns, or aggressive performance techniques, that are interesting from a technical perspective but not necessarily required in the majority of real-world applications.

In many production systems I’ve worked on, UI behavior is surprisingly simple: mostly static layouts with some interaction and, at most, basic hover effects. Even things like CSS animations are rarely used in practice (I’m still waiting for a real opportunity to use them in a professional context), let alone more advanced concepts like page transitions. As developers, we tend to be excited about these capabilities (I definitely am) but they often don’t materially impact the actual product.

From that perspective, optimizing frameworks around these concerns while testability remains difficult feels like a questionable trade-off. In day-to-day work, the real challenge is maintaining correctness and evolvability over time, and testability is a key enabler for that. It should arguably be a primary design goal, not an afterthought.

This becomes even more important in the current context where AI-assisted ...