React Testing Library 16.3.3: two packages to install, one runtime dependency, and a console.error patch for React 16.8

The library gives you queries, not access to component internals

The stated problem is refactors, not coverage. You want tests that avoid implementation details so that changes to how a component works do not break them, and the solution is described as a very lightweight set of utility functions on top of `react-dom` and `react-dom/test-utils`. The guiding principle is a single sentence: the more your tests resemble the way your software is used, the more confidence they can give you.

The API shape follows from that sentence. A test imports `render`, `fireEvent`, and `screen` from `@testing-library/react`, interacts with a checkbox the way a person would, and asserts on text. There is no documented API for reaching into a component's state or props, and the examples make the parallel explicit: the note in the first sample says the library works well with both React Hooks and classes, and that your tests will be the same regardless of how you write your components.

The consequence for a reader is a trade, not a gain. A test that only touches visible output is cheap to keep, and it fails when the user-visible behaviour breaks. It also cannot localise the failure: a red assertion tells you the component is wrong, not which line of the implementation caused it.

From version 16 the dom package moved out and became a peer

The install is two packages, not one, and the reason is a split that happened at version 16:

npm install --save-dev @testing-library/react @testing-library/dom

or with yarn:

yarn add --dev @testing-library/react @testing-library/dom

The manifest tells you why this is not a convenience detail. `@testing-library/dom` is listed under `peerDependencies` alongside `react` and `react-dom`, so the version of the query layer is decided by your project rather than by a dependency range, while the only entry in `dependencies` is `@babel/runtime` at `^7.12.5`. The package is MIT licensed and declares `engines` of node `>=18`.

What that costs an operator is one more version to keep in step. A mismatch between the dom package and the React package is yours to manage, since the version of the dom package is chosen by your project. The upside is that the runtime footprint of the library itself is one small helper package, which is a reasonable trade for utilities that mostly sit on top of React's own renderer.

Version 13 and newer need React 18, and older apps are pinned to 12

There is a hard React floor, and the fallback for older projects is a different major of the testing library. Versions 13 and up require React v18, and if your project uses an older React the instruction is to install version 12:

npm install --save-dev @testing-library/react@12

yarn add --dev @testing-library/react@12

Read that as a fork rather than a transitional step. A project on React 17 or older does not get a slightly older patch of the current line, it gets a library major that will not receive the fixes of the current one, and the repository does not describe a version of the current release that supports pre-18 React. The same split shows up in the development dependencies, where `@types/react` and `@types/react-dom` are at `^19.0.0`.

The practical consequence is that upgrading React and upgrading the test library are the same decision. There is no combination in which you take the new React and keep the current test library.

The React 16.8 fix monkey-patches console.error for the whole file

One documented workaround exists, and it is a suppression rather than a fix. React DOM 16.8 emits a known compatibility warning, `Warning: An update to ComponentName inside a test was not wrapped in act(...)`, and if you cannot upgrade to React DOM 16.9 you are told to silence it in your test configuration with a snippet that swaps out `console.error` for the duration of the suite:

// this is just a little hack to silence a warning that we'll get until we
// upgrade to 16.9. See also: https://github.com/facebook/react/pull/14853
const originalError = console.error
beforeAll(() => {
  console.error = (...args) => {
    if (/Warning.*not wrapped in act/.test(args[0])) {
      return
    }
    originalError.call(console, ...args)
  }
})

afterAll(() => {
  console.error = originalError
})

The shape of it is worth understanding before you paste it. The override is installed in `beforeAll` and restored in `afterAll`, so it covers every test in the file, and the filter is a regular expression match, meaning any error whose first argument mentions a warning not wrapped in `act` disappears from the log, not just the one React DOM 16.8 emits. A genuine act warning from your own code would also be swallowed, and the only signal left is the absence of a message. The comment in the snippet says as much, calling it a hack for a warning that goes away at 16.9.

Every example configures Jest, and no Vitest path is documented

The runner assumption runs through the whole example set. The test file for the simple component opens with imports that the comment says you would normally configure Jest to import for you automatically, pointing at the setup documentation for cleanup, and it adds `@testing-library/jest-dom`, described in a second comment as adding handy assertions to Jest and being recommended but not required. The more complex example does the same and then adds network mocking through Mock Service Worker with `rest` from `msw` and `setupServer` from `msw/node`, which is how a component that calls `window.fetch` against `/api/login` gets a response without a live server.

The repository's own tooling matches that story: there is a `jest.config.js` at the root and the `test` script runs through `kcd-scripts`.

What a reader cannot get from these pages is a setup for a different runner. The README examples shown are written around Jest.

Three builds ship, and one of them exists to drop a side effect

The manifest publishes three entry points and a build that runs them in parallel. `main` is `dist/index.js`, `module` is the ESM bundle `dist/@testing-library/react.esm.js`, and there is a third build produced with an extra dotenv file, `.bundle.pure.env`, layered on top of `.bundle.main.env` by the `build:bundle:pure` script while `build:bundle:main` uses only the first. The `build` script runs `build:main`, `build:bundle:main`, and `build:bundle:pure` together with `npm-run-all --parallel`, and `prebuild` clears `dist` with rimraf first.

The published file list is where the purpose becomes visible: `dist`, `types/*.d.ts`, `pure.js`, `pure.d.ts`, and a root file named `dont-cleanup-after-each.js`. Those last two are the escape hatches. The library performs cleanup between tests, and the setup documentation is the place that behaviour is configured, so a project that wants to manage unmounting itself can import the opt-out file or resolve the pure entry point instead.

The trade is that the pure entry point skips the automatic cleanup.

The manifest version is a placeholder and the releases are irregular

The version in package.json is `0.0.0-semantically-released`, a placeholder replaced at publish time, so the number you see in a checkout tells you nothing about the code. The real history is in the tags: v16.3.1 on 2025-12-15, v16.3.2 on 2026-01-19, and v16.3.3 on 2026-08-27, with the last push to main on 2026-08-27. The repository is not archived.

The spacing between those tags is uneven, a month between the first two and seven months before the third, so patch releases do not arrive on a schedule you can plan around. The contributor side has its own set of fixed points: `validate` and `lint` and `format` all go through `kcd-scripts`, `typecheck` runs `tsc --project tsconfig.json`, `setup` is `npm install && npm run validate -s`, and `test:update` runs the suite with `--updateSnapshot --coverage`, which is the command that rewrites snapshots when a rendering change is intended rather than accidental.

For a consumer the consequence is simple. Pin an exact version rather than a caret, and expect to read the changelog when you move.

Editorial conclusion

React Testing Library fits React projects on version 18 or newer that want tests written through queries rather than internals, and that accept Jest as the runner the examples assume. It does not fit a project still on React 17, which has to stay on version 12. Before upgrading, check the React major you are on, install the dom package alongside it, and decide whether you want the automatic cleanup side effect or the pure build without it.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. testing-library/react-testing-library on GitHub