my agent replaced a racy assertion with waitForSelector but picked the wrong element, so it passes without checking...

TL;DR

A wait is only as good as what it waits for. If the selector matches an element that exists regardless of the behavior you're testing, the test passes without checking anything: a green test with zero assertions. Verify the selector targets an element whose presence actually proves the expected outcome, and confirm the test goes red when the feature is broken.

The query

my agent replaced a racy assertion with waitForSelector but picked the wrong element, so it passes without checking anything

Steps

1. State what the test is supposed to verify

Write down, in one sentence, the behavior the original assertion checked. Not the selector, the behavior: "the success message appears after submit," "the row is added to the table."

Expected: a plain-language statement of the expected behavior.

2. Check what the current selector actually matches

Find the element the waitForSelector targets. Ask: does this element's presence prove the behavior from step 1? An element that exists on page load, or that appears for unrelated reasons, proves nothing.

Expected: a verdict on whether the selector is coupled to the expected behavior or coincidental.

3. Fix the selector to the proving element

Point the wait at the element that only appears (or only reaches its expected state) when the behavior is correct: the success message itself, the new row with the expected content, the button's enabled state. Prefer roles and text the user would see over implementation details.

Expected: a selector whose match logically implies the expected outcome.

4. Prove the test can still fail

Break the feature deliberately (revert the fix, mock a failure) and run the test. It must go red. A test that can't fail is not a test.

Expected: the test fails with the feature broken and passes with it working. The wait now asserts something real.

Use this when

• An agent converted a racy assertion into a wait and the test now passes "too easily"
• The test passes even when you suspect the feature is broken
• The selector matches something static (a container, a header, a loading spinner)
• Reviewing the test, you can't explain what would make it fail

Not for this skill when

• The selector correctly targets the behavior's evidence (then the conversion was fine)
• The test fails appropriately (a passing test that can fail is not vacuous)
• The original assertion is still in place alongside the wait (belt and suspenders is fine)
• The problem is timing, not targeting (then the wait pattern is right, the durations need work)

Variant phrasings

agent waits for the page container instead of the result

The container exists before the action completes. Waiting for it asserts that the page loaded, which you already knew.

the test passes with the feature flag off

If the test can't tell the feature is disabled, its selector is decoupled from the behavior. That is the definitive vacuous-test check.

waitForSelector on a spinner that disappears

Waiting for a loading indicator to vanish proves the load finished, not that it succeeded. Wait for the success state.

Why it happens

The agent's goal in the conversion is "make the race go away," and any waitForSelector achieves that: the test stops flaking because it stops asserting anything timing-sensitive. The agent picks the first selector that makes the wait resolve, usually something stable and easy to find, without checking whether that element is evidence of the expected behavior. Its verification (rerun the test, it's green) can't distinguish a meaningful wait from a vacuous one, because both are green. Only the negative check, "does it fail when the feature breaks," tells them apart, and the agent never runs it.

Edge cases

• The right element is hard to select (no role, no text, dynamic classes): add a test id or use a user-visible assertion instead of settling for a coincidental selector.
• Multiple elements match and the first is the wrong one: strict-mode violations or first-match semantics can silently pick the coincidental element. Make the selector specific.
• The behavior's evidence is the ABSENCE of something (an error that shouldn't appear): waiting for presence can't express that. Assert the absence explicitly after the action settles.
• The agent converted many assertions in one pass: audit all of them with the break-the-feature check, not just the one that looked suspicious.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jWMxqGXLEtj5WCvlIXMnBQ

Resolved from the public thread: https://vectle.com/posts/pst_jWMxqGXLEtj5WCvlIXMnBQ

Thread query: my agent replaced a racy assertion with waitForSelector but picked the wrong element, so it passes without checking anything

TL;DR: A wait is only as good as what it waits for. If the selector matches an element that exists regardless of the behavior you're testing, the test passes without checking anything: a green test with zero assertions. Verify the selector targets an element whose presence actually proves the expected outcome, and confirm the test goes red when the feature is broken.