Skip to content

Wait on a condition in every scenario that reads after one - #209

Merged
vmillet-dev merged 1 commit into
mainfrom
wait-on-a-condition-everywhere
Sep 18, 2026
Merged

vmillet-dev merged 1 commit into
mainfrom
wait-on-a-condition-everywhere

Conversation

@vmillet-dev

Copy link
Copy Markdown
Owner

Closes #197.

#190 swept six sleeping assertions and its grep was wrong — a one-line lookahead
demanding a literal expect( on the very next line, which misses a value read now
and asserted two lines down, and anything behind a blank line. Counted properly, 42 of
the 46 browser.pause calls in e2e/specs/ were followed within four lines by a read
or an assertion.

What changed

before after
browser.pause in the specs 46 3
followed by a read or an assertion 42 0

Each one was replaced with eventually(read, matches, what) and the condition that
actually applies, file by file — a wrong condition is a test that passes for the wrong
reason.

The three kept say why they are kept: an assertion that nothing happened is not a
condition anything can wait on. Two already carried that comment; the third is the tag
manager's cancel.

15-preferences-on-disk no longer outwaits the store plugin's debounce. The file
is the condition, so it is polled from Node — which also drops four fixed 1.5 s waits
to whatever the flush actually costs.

The rule is now executable

scripts/e2e-waits.test.mjs (npm run test:scripts) fails on a browser.pause
followed within four lines by a read or an assertion, unless a comment above says the
wait is deliberately one. Confirmed to fail on an injected violation, so the sweep
cannot quietly come undone the way #190's did.

Two rewrites taught something

  • Submitting a dialog and waiting only on the stored value returns sooner than the
    old sleep, before the dialog has closed — and the next scenario opened a settings panel
    over it. A duration hides more than the thing being asserted.
  • A wait on an end state ("filed in this folder") timed out twice, through the bridge
    and through the DOM. Split into "written at all" then "filed", it passes — and a
    timeout now names which step failed.

Verified

E2E 21/21 twice in a row, which is the point of the ticket rather than a formality.
Unit 1354/1354, test:scripts 34/34, lint clean. CLAUDE.md updated: the rule was
already written there, but it said two exceptions and named two script-test files.

#190 swept six sleeping assertions and its grep was wrong: a one-line
lookahead demanding a literal 'expect(' on the very next line, which misses a
value read now and asserted two lines down, and anything behind a blank line.
Counted properly there were 42.

They are replaced with 'eventually(read, matches, what)', file by file, each
with the condition that actually applies. Three are kept and say why: an
assertion that *nothing* happened is not a condition anything can wait on.
The four in '15-preferences-on-disk' now poll the file from Node instead of
outwaiting the store plugin's debounce.

'scripts/e2e-waits.test.mjs' holds the rule with a lookahead that works, so
the sweep cannot quietly come undone.

Two of the rewrites taught something the sweep alone would not have:
submitting a dialog and waiting only on the stored value returns sooner than
the sleep did, before the dialog has closed and the next scenario opens a
panel over it; and a wait on an end state is worth splitting into the steps
that lead there, so a timeout names which one failed.

Closes #197
@vmillet-dev
vmillet-dev merged commit 57c1817 into main Sep 18, 2026
11 checks passed
@vmillet-dev
vmillet-dev deleted the wait-on-a-condition-everywhere branch September 18, 2026 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The sleep sweep covered a sixth of the sleeps

1 participant