test: deterministic exercises for every web verb in the testbed and one twin per web-benchmark scenario

Merged
OK
1mo ago
+2881-787

Stacked on oskar/scroll-until-visible-scoped (the pane and infinite-scroll tests use the scoped scroll).

Every verb the runner exposes gets a deterministic exercise on a real browser, so a red agentic run is the model, not the tools.

SuiteBeforeAfter
testbed41 tests, 10 pages68 tests, 14 pages, 16 s
web-benchmark deterministic twins5 of 41 scenarios38 of 41 (the other three land with their engine fixes)
  • Testbed pages /controls, /scroll, /browser, /speed, /about cover what no suite touched: secondaryTap, longPress, scrollIntoView, a scoped and a viewport scrollUntilVisible over windowed lists, waitForURL, isChecked, filter({ has }), viewport and raw mouse, cookies, every state matcher, and the negative paths (LOCATOR_AMBIGUOUS, LOCATOR_NOT_FOUND, INVALID_LOCATOR).
  • The playground server is five page modules and a generated nav (app/server.mjs 1025 lines to 87); the speed suite pins a per-action floor as a ratio against a measured read cost.
  • One twin per web-benchmark scenario under tests/<slug>.e2e.ts, locators and expect only. tests/support.ts holds the shared helpers once (read a code off the page, the centre of a node, the error a step throws, the element beside a visible label); tests/canvas.ts the pixel reads. A planted-bug scenario asserts what the page truly shows, bug named in the title.
  • The twins for new-tab-flow, shadow-dom-form, and file-round-trip land with waitForPopup, closed-root locators, and absolutePath in the next pull requests of the stack.

Devin Review