A React Testing Library test clicks Save and then asserts `expect(screen.queryByText('Saving…')).not.toBeInTheDocument()`. Why can that assertion pass even when the spinner logic is broken, and what does waitForElementToBeRemoved give you instead?

## Negative assertions have no notion of "yet" `expect(queryByX(...)).not.toBeInTheDocument()` asks one question at one instant: is this element in the DOM right now? For anything asynchronous, "not yet" and "not any more" produce identical answers. That is the entire defect. Immediately after a click, an async save has not yet committed its loading render, so the query finds nothing and the assertion passes — while proving nothing at all. The test is worse than useless because it looks thorough. It survives deleting the spinner, renaming its text, breaking the save handler, and leaving the spinner up forever. A vacuous pass is a test that will never go red for the bug it was written to catch. ## What waitForElementToBeRemoved adds The helper encodes the two-phase claim the test actually wants to make: ```js await user.click(screen.getByRole('button', { name: 'Save' })) await waitForElementToBeRemoved(() => screen.queryByText('Saving…')) ``` On the first call it evaluates the callback, and **if the element is already absent it throws** with an explicit message saying the element must exist before you can wait for its removal. That converts the silent vacuous pass into a loud failure. Then it waits, on the same retry machinery as `waitFor`, until the element disappears or the timeout expires. Two call forms exist. Passing an **element** works when you have already captured it and it will not be replaced. Passing a **callback** that re-queries is safer in React, where a re-render can swap the node for a different instance carrying the same text — with a stale element reference you may end up waiting on a node that was detached long ago while a fresh one is still on screen. ## The ordering problem it does not solve Even with the right helper, you have to observe the loading state before it ends. If saving resolves in under a millisecond because the network is mocked with an already-resolved promise, the spinner may never be observable, and the helper will fail on "already removed" — a false *red*. That is a signal about the test's seam, not about the component: either the mock should introduce a controllable delay so the loading state is genuinely reachable, or the loading state does not deserve an assertion here. ## Often the right move: assert the outcome Ask what the test is protecting. If the answer is "the user sees confirmation after saving", then the spinner is a step along the way and the confirmation is the contract: ```js await user.click(screen.getByRole('button', { name: 'Save' })) expect(await screen.findByText('Saved')).toBeInTheDocument() ``` This is positive, it cannot pass vacuously — the text has to actually appear — and it survives the team replacing a spinner with a progress bar or a skeleton. Wait for the removal only when the disappearance itself is the behaviour under test: a dismissible toast, a modal that must close after confirm, an overlay that must not stay stuck. ## The general rule for negative assertions A negative assertion is only meaningful when it is anchored to a moment you have established. Two shapes are trustworthy: - **After a positive await.** `await screen.findByText('Saved')` first, then `expect(screen.queryByText('Saving…')).not.toBeInTheDocument()`. The settled state is now established, so the negative means something. - **Inside an explicit removal wait**, as above, where presence is verified before absence is awaited. What is never trustworthy is a bare negative fired straight after an action. The same reasoning applies to asserting that an error message is absent, that a row was deleted, or that a request was not sent: check at a moment you have proved the system reached, not at an arbitrary instant on the way there.