In a React Testing Library `renderHook` test, a value destructured out of `result.current` before an update still shows the old number when you assert afterwards. Why, and what do you write instead?

## The mechanism A hook returns a fresh value on every render. A test, however, runs as one straight-line function. Bridging those two requires a mutable box that the test can look inside after each render — that box is `result`, and the box's slot is `result.current`. The helper does roughly this on every render of its stub component: ```js result.current = callback(); // the hook's newest return value ``` That is an assignment to a property, not a mutation of the previous value. The object that was in `.current` a moment ago is untouched and now unreferenced by the helper. Anything you copied out of it — a number, a string, a function reference — belongs to a render that has already been superseded. ```js const { count } = result.current; // count === 0, forever act(() => result.current.increment()); count; // still 0 — a copy of the old render's value result.current.count; // 1 — the current render's value ``` ## Why this trips people up The same pattern would work in most other testing contexts. If you get an object back from a normal function and it is later mutated in place, your destructured reference is not stale, because you would have held the same object. Hook returns are different by design: state is immutable per render, and each render produces a *new* return value rather than editing the old one. That is the same rule that produces stale-closure bugs in application code, showing up in test code. The result is a class of test failure that reads like a framework bug — "the hook clearly increments, but my assertion says zero" — when in fact the assertion is looking at a snapshot from before the update. ## The habit that avoids it Keep the full path in the assertion: ```js expect(result.current.count).toBe(1); expect(result.current.status).toBe('ready'); ``` And call actions through the box too: ```js act(() => result.current.setStatus('loading')); ``` Calling a *saved* action reference often appears to work, because the state setters the framework hands you keep a stable identity across renders. That is a trap: as soon as the hook returns a hand-written callback that closes over its own state — `const submit = () => save(draft)` — a saved reference will run against an outdated `draft`, and the test will assert against behaviour no real consumer would ever get, since a real consumer re-reads the hook's return every render. Always going through `result.current` makes the test match what a component actually does. ## Related pitfalls in the same family - **Snapshotting the whole return object.** `const api = result.current` has the same defect as destructuring one field; the object itself is the stale thing. - **Asserting before the update flushes.** If you read `result.current` before the state update has been applied, you see the pre-update render for a different reason — the render has not happened yet. Both mistakes produce the same wrong number, so check which one you have: is the value stale because you copied it, or because nothing re-rendered? - **Holding on across a rerender with new arguments.** Re-invoking the hook with different inputs produces yet another return value; every previously captured reference is stale after it. ## Why the API is shaped this way It would be nicer if the helper simply returned the hook's value, but a returned value cannot change after the fact. The box exists so a synchronous test body can observe an inherently multi-render process. Once you see `result` as a live window rather than a value, the rule stops feeling arbitrary: read through the window every time you want to know what the hook says *now*.