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.

In the diagram, the left side shows an implementation-focused test. Arrows connect the test to internal state, specific hook calls, and component structure. When a refactor happens (for example, state is lifted or logic is reorganized), those arrows break. The test fails even though the UI is still correct.

The right side shows a behavior-focused test. The arrows connect only to user interactions and visible output. A refactor can change the internal wiring, but the arrows remain intact because the user-visible behavior is unchanged. The test continues to pass.

React’s coordination model and the stability of behavior

In React 19, rendering is coordinated and scheduled work. A state update does not immediately and synchronously mutate the DOM; it enters React’s scheduling system. React determines how and when that work commits. Concurrency features allow parts of the tree to update independently. Suspense boundaries can delay regions of the UI without freezing everything else.

All of this reinforces one principle: implementation is fluid.

Observable behavior, however, is stable. Observable behavior consists of what appears in the DOM, what the user can interact with, and what changes after that interaction. That is the rendering contract.

When we write behavior-focused tests, we assert against that contract. We render the component as a user would experience it. We query ...