Testing Fundamentals in React

In many production React codebases, tests begin as helpful safety nets and gradually become a source of friction. A team introduces concurrency features, refactors state management, extracts smaller components, or replaces local state with server-driven data. The user experience remains correct, but dozens of tests fail. The failures are not signaling broken behavior; they are signaling broken assumptions about how the component was built.

This problem usually starts innocently. A test asserts that a specific component renders a certain child. Another spies on an internal handler. Another checks that a particular state variable changed. At first, this feels precise. Over time, it becomes fragile. As the architecture evolves, especially in React 19, where scheduling, transitions, and rendering coordination are first-class concepts, the internal mechanics naturally shift.

React 19 does not promise stable implementation details. It promises a stable rendering outcome. Updates may be deferred. Transitions may reprioritize work. Components may suspend. State may move across boundaries. These are architectural improvements, not user-facing changes. If our tests are tied to the mechanics rather than the outcome, they fight the architecture rather than protect it.

The real issue, then, is misidentifying what we are supposed to test. We are not testing hooks. We are not testing component composition. We are testing whether the interface behaves correctly from the user’s perspective. This lesson addresses that misalignment directly.