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 development is becoming more common. AI tools are very good at producing code quickly, but they are also very good at introducing subtle regressions. In that environment, a strong automated test suite (ideally following the test pyramid) becomes essential. The goal is to reach a level of confidence where applying AI-generated changes does not introduce fear, because the tests provide fast and reliable feedback. That only works if tests are fast, isolated, and easy to write, which again brings us back to testability as a core design concern.
Ideally, I’d expect the framework to guarantee correct behavior at the environment boundary. From an application perspective, tests should focus on verifying behavior against the framework’s public API, not re-specifying the runtime details the framework is supposed to hide.
I don’t think Testing Library is the main problem here. It feels more like a symptom of a deeper issue: testing React components is hard because of how React is designed. Testing Library doesn’t really fix that, it just works around it by pushing tests toward a more integration-style approach. The real problem is testability itself. If React made it easier to write small, isolated tests, tools like Testing Library wouldn’t need to fill that gap. In that sense, the root cause isn’t the testing tools, but the framework, and that’s where improvements would have the biggest impact.
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 development is becoming more common. AI tools are very good at producing code quickly, but they are also very good at introducing subtle regressions. In that environment, a strong automated test suite (ideally following the test pyramid) becomes essential. The goal is to reach a level of confidence where applying AI-generated changes does not introduce fear, because the tests provide fast and reliable feedback. That only works if tests are fast, isolated, and easy to write, which again brings us back to testability as a core design concern.
Ideally, I’d expect the framework to guarantee correct behavior at the environment boundary. From an application perspective, tests should focus on verifying behavior against the framework’s public API, not re-specifying the runtime details the framework is supposed to hide.
I don’t think Testing Library is the main problem here. It feels more like a symptom of a deeper issue: testing React components is hard because of how React is designed. Testing Library doesn’t really fix that, it just works around it by pushing tests toward a more integration-style approach. The real problem is testability itself. If React made it easier to write small, isolated tests, tools like Testing Library wouldn’t need to fill that gap. In that sense, the root cause isn’t the testing tools, but the framework, and that’s where improvements would have the biggest impact.