Migrating from Enzyme to React Testing Library: Strategy, Tools, and Lessons Learned at Tubi

Tubi's front‑end codebase, started in 2015, has consistently followed React community best practices, keeping core frameworks and dependencies up‑to‑date. The team, driven by strong technical self‑motivation and management support, allocates at least 20% of time to infrastructure and technical upgrades.

The migration from Enzyme to React Testing Library (RTL) began at the end of 2022 and was a major effort for the product front‑end. Four key reasons motivated the switch: Enzyme is no longer actively maintained and lacks React 18 support; RTL promotes more maintainable integration tests; RTL encourages testing from a user‑centric perspective with built‑in accessibility checks; and RTL has a vibrant, long‑term community.

RTL’s “Test Trophy” model emphasizes UI integration tests, which combine API mocking, user interactions, and accessibility validation. This approach allows a single UI test to cover rendering, data loading, permissions, and underlying Redux state, reducing the need for separate unit tests.

Example comparisons show Enzyme locating a button via a class name and inspecting component state, while RTL uses semantic queries like getByLabelText and getByRole to verify UI behavior without coupling to implementation details.

To manage the large migration scope (over 440 test files, >100 k lines), Tubi adopted a phased strategy: new features must use RTL, while existing Enzyme tests are migrated incrementally using custom tools. A lint rule (startDate 2022‑12‑16) prevents new Enzyme tests, and an npm command yarn run rtl-migrate reports overall and per‑folder migration progress.

Automation was achieved with custom codemods built on jscodeshift . The team identified the most common Enzyme patterns and wrote transformers to convert them to RTL equivalents, applying motions such as render, snapshot, find‑text, and user‑event conversions. The codemod pipeline is modular, allowing independent transformers to run in sequence.

const transform: Transform = (file, api, options) => {
  const j = api.jscodeshift;
  const { source } = file;
  const ast = j(source);
  // NOTE: The order of motions is important. Some motions need to be applied before others.
  applyMotions(j, ast, [
    ...renderMotions,
    ...snapshotMotions,
    ...findTextMotions,
    ...inTheDocumentMotions,
    ...userEventMotions,
    // More transform-related motions...
  ]);
  return toSource(ast, options.toSourceOptions);
};

Because RTL does not expose component instances, a custom renderWithInstance helper was created to retain access to the underlying class for legacy tests that rely on wrapper.instance() . This bridge allowed gradual migration without rewriting all tests.

The migration took roughly two and a half months, involving 109 development tasks, conversion of 466 test files, and over 100 k lines of test code. Progress was visualized with burn‑down charts, showing the impact of code freezes and team allocation.

Key takeaways include the importance of incremental migration, applying the 80/20 principle to tool development, involving the whole team early, and clearly defining codemod scope to avoid over‑investment. The successful switch to RTL also improved test maintainability, execution speed, and accessibility awareness across the front‑end team.