Deterministic replay

Why replays are fast, model-free and resistant to the usual sources of flakiness.

Recorded tests replay with no model in the loop. The rules:

• Cached locators, web-first assertions, auto-wait only.
• No fixed sleeps and no idle-network waits. Readiness is your app's own signal.
• Sessions are created deterministic: animations and transitions off, the clock pinned, random seeded, reduced motion emulated. Each test gets a fresh browser context.
• Free riders on every step: console errors, uncaught exceptions and unexpected 4xx/5xx responses are collected; a page error or a 5xx fails the step.

The readiness signal

The broker arms the check when the browser announces a navigation request, before any request is in flight, so a form submit is verified against the next document rather than the one being left. Two consecutive good polls confirm readiness. Typical cost is 30 to 60 milliseconds after a navigating action and nothing otherwise.

Typing

Replay types with a single insert-text command followed by a real Enter when the step submits. Per-character key events remain reserved for a human's own keystrokes during a takeover, where they are what the page expects.

Actionability

A step waits up to 1.5 seconds for its element to have a layout box, scrolling it into view and retrying, and then fails with a typed message. A rejected act is a failed step, not an infrastructure retry, so a broken locator is reported as such and can be healed.

The benchmark

A test in the suite replays a recorded case and fails if the median non-navigating step exceeds 150 milliseconds. It runs on every change to the replay path.