React Strict Mode Testing

React Strict Mode is a development-time mechanism that helps reveal unsafe side effects and lifecycle assumptions by deliberately exercising certain component behavior more than once. In tests, this can expose effects that are not idempotent or whose cleanup is incomplete.

Strict Mode is enabled by wrapping a component subtree in `<StrictMode>` or configuring it at the application root. It does not represent production runtime behavior; its purpose is to surface problems during development.

One important development behavior is that React may render components more than once and may perform an extra setup-and-cleanup cycle for effects. This helps reveal code that performs side effects during rendering or assumes an effect runs only once without correctly cleaning up.

When testing with React Testing Library, you can render a component inside `<StrictMode>` to exercise these checks. A test should generally verify the observable behavior and proper cleanup rather than assert an exact number of development-only effect executions.

For example, an effect that subscribes to an event should return cleanup code that removes the subscription. Under Strict Mode, the additional setup and cleanup cycle can expose missing cleanup because duplicate subscriptions or leaked resources become visible during the test.

Key points

• Strict Mode checks are primarily development-time safeguards, not production behavior.
• Effects should be written with complete setup and cleanup so repeated development cycles are safe.
• Tests can wrap rendered components in `<StrictMode>` to expose unsafe side effects.
• Avoid asserting development-only effect invocation counts unless the test specifically targets that behavior.
• Prefer testing user-visible behavior and resource cleanup over implementation details.

Interview questions

Why might a `useEffect` appear to run twice in a React test?

If the component is rendered under Strict Mode, React may perform an extra development setup-and-cleanup cycle for effects. This is intentional and helps identify effects that are not safe to repeat or clean up correctly. It does not mean the production application will necessarily perform the same sequence. The correct response is usually to make the effect setup and cleanup symmetrical rather than suppressing the second execution.

How should you test a component that has an effect under Strict Mode?

Render the component inside `<StrictMode>` when you want the test environment to exercise these development checks. Then assert observable behavior, such as rendered output, user interactions, or correct external-resource behavior. If the effect manages a resource, verify that cleanup prevents leaks or duplicate behavior. Avoid coupling the test to React's internal development invocation count unless that count itself is the behavior being tested.

What kind of bug is Strict Mode particularly good at exposing?

It is useful for exposing side effects that are performed during rendering and effects whose setup is not safely repeatable. Missing cleanup is another common problem, especially for subscriptions, event listeners, timers, and connections. The extra development checks can make these defects visible earlier. The underlying fix is to keep rendering pure and make effect setup have corresponding cleanup.

Why is asserting an exact `useEffect` call count usually a fragile test?

Effect invocation can depend on React's development behavior, including Strict Mode, as well as dependency changes and component lifecycle transitions. An exact count therefore often tests an implementation detail rather than the contract users care about. A stronger test verifies the resulting behavior and resource lifecycle. If invocation count is itself important, the test should clearly document the specific environment and reason for that assertion.