In React Testing Library, where does render() actually put the component, and what does the library's automatic cleanup do between tests?

## What render() does `render(ui)` is the mount step of a component test. It does three concrete things: 1. Creates a container element — a plain `div` — and appends it to `document.body` (the `baseElement`). 2. Mounts `ui` into that container using a real React root, inside the library's `act()` handling so effects flush. 3. Returns a result object with `container`, `baseElement`, `rerender`, `unmount`, `asFragment`, and query functions bound to that container. The important consequence is that there is nothing virtual about the result. The component's real elements exist in a real (jsdom or browser) document, so you can assert on text, attributes, focus and visibility the way a user's browser would present them. ```js import { render, screen } from '@testing-library/react' test('shows the label', () => { render(<Badge>New</Badge>) // screen queries document.body, which now contains the container div expect(screen.getByText('New')).toBeInTheDocument() }) ``` `screen` is simply the query set bound to `document.body`, which is why it finds anything `render` mounted without you passing the container around. ## Why cleanup exists A test file is one document. Each `render` call appends another container, and nothing removes it on its own — jsdom does not reset the document between tests, and the React root stays mounted with its effects, subscriptions and timers alive. Left alone, a five-test file ends with five copies of your component in the body. That produces the classic symptom: a query fails not because the element is missing but because it matched too many. `getByText` and friends throw when more than one node matches, so test three fails with a "found multiple elements" error that has nothing to do with test three. The library solves this by registering a global `afterEach` hook at import time that calls `cleanup()`. `cleanup` unmounts every root the library mounted and removes every container it added, returning the document to the state the test started in. ```js // conceptually what the library registers for you afterEach(() => { cleanup() // unmount all mounted roots, remove their containers }) ``` ## When it does not happen The registration depends on a global `afterEach` existing at import time. If your runner is configured without global test hooks — for example a runner where `describe`/`it`/`afterEach` are imported explicitly rather than exposed globally — the library has nothing to hook into and auto-cleanup silently does not run. The fix is a setup file that imports `cleanup` and calls it in `afterEach` yourself. There is also a deliberate opt-out (`RTL_SKIP_AUTO_CLEANUP`) for the rare suite that wants to manage mounting itself; needing it is unusual. A good diagnostic instinct: if tests pass individually and the failures are all "found multiple elements" or stale text from a previous case, suspect cleanup before suspecting the component. ## What cleanup does not do Cleanup is DOM-scoped. It does not: - reset module mocks, spies or call counts; - restore fake timers; - reset anything you built outside the render — a store, a cache client, a module-level singleton; - undo global changes the component made, such as a class added to `document.documentElement` by a portal or theme provider, if the component does not remove it on unmount. That last one is worth knowing because it is also a real assertion opportunity: `unmount()` from the render result lets you check that a component tears itself down properly — removes its listeners, aborts its work, clears the body class — rather than leaking. ## What interviewers are really checking The question looks trivial, but it separates candidates who treat the test DOM as a shared, stateful resource from candidates who assume magic isolation. The principle generalises past this one library: any component test mounts into a persistent document, and test independence is something the harness must actively restore between cases. If a suite ever starts failing only when run together, the first hypothesis is leftover state — DOM first, then everything cleanup does not cover.