react-test-renderer: Deprecation, Risks, and What to Use Instead

react-test-renderer is deprecated and no longer maintained as of React 19, and the React team recommends migrating your tests to Testing Library instead. If you have react-test-renderer in your package.json and are planning a React 19 upgrade, this is a dependency you need a plan for, not one you can carry forward indefinitely. Calling ReactTestRenderer.create() now emits a deprecation warning, and the package will remain on npm but may break as React's internals evolve.

For teams that relied on it for snapshot testing over the years, the deprecation is a nudge that arrived late but is worth heeding now.

What react-test-renderer Was For

react-test-renderer let you render React components to a pure JavaScript object tree, with no DOM and no browser. That made it useful for snapshot testing (serialize the tree, diff it against a saved snapshot) and for testing React Native components where there is no DOM at all. Many older Jest setups leaned on it heavily.

The install is the familiar shape you will find in a lot of legacy suites:

npm install --save-dev react-test-renderer

The problem is not the API itself; it is that the API works by reaching into React's internals, which is exactly the coupling React now wants to break.

Why It Was Deprecated

The React team deprecated react-test-renderer because it depends on internal React behavior that is increasingly hard to keep stable across major versions. As React added concurrent rendering and reworked internals, maintaining a renderer that mirrors those internals for test purposes became a liability. The official guidance is blunt: the package will stay available on npm but will not be maintained and may break with new React features.

There is a concrete breaking change to know about. The shallow renderer, react-test-renderer/shallow, was removed entirely in React 19. If your tests import from that path, they will not work after the upgrade, full stop.

The Risks of Staying on It

A deprecated, unmaintained testing dependency is a slow-burn risk rather than an acute one, but it is real:

• It will drift out of compatibility. As React ships new versions, an unmaintained renderer that depends on internals is likely to break in subtle ways, and no fix will come.
• It blocks React upgrades. If your suite depends on removed APIs like the shallow renderer, react-test-renderer becomes a blocker to adopting React 19 and beyond.
• It accumulates as stale surface. Unmaintained dependencies are exactly what dependency scanners flag, and an SCA tool will surface a deprecated, no-longer-updated package so it does not sit unnoticed in your lockfile for years.

None of this means your tests fail tonight. It means the cost of migration only grows.

What to Use Instead

The React team recommends @testing-library/react for web and @testing-library/react-native for native. Testing Library takes the opposite philosophy from react-test-renderer: instead of inspecting an internal tree, it renders to a real DOM (via jsdom) and queries the output the way a user would, by role, label, and text. That decoupling from internals is precisely why it survives React upgrades gracefully.

// Old: react-test-renderer snapshot
import TestRenderer from 'react-test-renderer';
const tree = TestRenderer.create(<Button label="Save" />).toJSON();
expect(tree).toMatchSnapshot();

// New: Testing Library, asserts on user-visible output
import { render, screen } from '@testing-library/react';
render(<Button label="Save" />);
expect(screen.getByRole('button', { name: 'Save' })).toBeInTheDocument();

The migration is also an opportunity to improve test quality. Snapshot tests over an internal tree tend to be brittle and to assert on structure nobody cares about. Testing Library nudges you toward assertions about behavior and accessible output, which break less often and catch more real regressions.

Planning the Migration

You do not have to convert everything at once. A practical sequence:

1. Inventory usage. Grep for react-test-renderer imports, and separately for react-test-renderer/shallow, since the shallow cases are urgent for a React 19 move.
2. Add Testing Library alongside. Both can coexist during the transition, so you can migrate file by file.
3. Convert shallow-renderer tests first. They are the ones that will hard-break on React 19.
4. Replace snapshot tests with behavior assertions where the snapshot was not adding value, rather than mechanically porting brittle snapshots.
5. Remove react-test-renderer from package.json once the last import is gone, and confirm your scanner no longer flags it.

For React Native suites, the same shape applies with @testing-library/react-native, which is the sanctioned replacement for native integration tests.

The Takeaway

react-test-renderer served a long stretch of React's history well, but its deprecation in React 19 is a clear signal. Treat it as a managed migration: inventory it, move urgent shallow-renderer cases first, adopt Testing Library incrementally, and remove the dependency once nothing imports it. The result is a test suite that is both more resilient to React upgrades and better at catching the regressions that matter.

FAQ

Is react-test-renderer deprecated?

Yes. As of React 19 it is deprecated and no longer maintained. It remains available on npm but the React team has stated it may break with new React features, and calling ReactTestRenderer.create() now logs a deprecation warning.

What replaced react-test-renderer?

The React team recommends @testing-library/react for web applications and @testing-library/react-native for React Native. Testing Library queries rendered output the way a user would instead of inspecting React internals, which keeps it stable across React versions.

What breaks in React 19?

The shallow renderer at react-test-renderer/shallow was removed entirely in React 19. Any tests importing from that path will stop working after the upgrade, so migrate those first.

Can I keep using react-test-renderer for now?

You can, since it stays on npm, but it is unmaintained and will drift out of compatibility as React evolves. It can also block future React upgrades, so plan an incremental migration to Testing Library rather than carrying it forward indefinitely.