OTP and magic link testing: the two parts every SERP skips.

What every top-ten result actually says

MailSlurp, Scalekit, JumpCloud, Auth0 docs, Supabase docs. Five of the five stop at the same high level: fresh inbox per run, poll with a timeout, match the code with a regex, assert the logged-in state. Every one skips the code for the regex, skips the split-digit pattern entirely, and none of them addresses the magic-link-in-a-second-tab trap that breaks Playwright sessions the moment you click through an email client.

Here are the two parts they skip, with source links into the product so you can read the implementation and copy it into your own tests even if you never install Assrt.

Part 1: the 7-regex cascade for code extraction

Real OTP emails do not consistently say "Your code is 483921". They say "Use this to sign in: 483921", or wrap the code in a styled <strong> with line breaks inside, or quote-printable-encode it across two lines. A single /\d6/ catches most of them and misses a long tail (order numbers, unsubscribe IDs, tracking pixels with numeric hashes). Assrt runs seven in priority order, most specific first. Labelled codes win over bare digits.

Before the regex runs, the code prefers body_text and falls back to stripping tags from body_html, then decoding   and numeric entities, then collapsing whitespace. That pre-step is why the patterns below only have to care about a clean string. The same function also returns the full decoded body (up to 5000 chars) so magic-link URL extraction is a second regex on the same payload.

Part 2: the split-digit OTP trick nobody writes about

Half the modern web uses a 4-to-6 input OTP form where every digit gets its own <input maxlength="1">. Clerk, Stripe, Supabase Auth, Shadcn InputOTP, MUI, Chakra PinInput. Every one of those components wires its splitter to the onPaste event, not onChange. A naive Playwright loop that .fill each field fights with the component's own focus management and will intermittently land only the first digit.

Three things make this work. First, the ClipboardEvent is dispatched on the parent container, not any individual input, because the component listens up the tree. Second, the event bubbles, so React's synthetic event system delivers it to the handler that owns the splitter. Third, DataTransfer is a real DOM type and React reads from it the same way it would for a user paste. One round trip fills every field. No per-digit typing, no focus sequencing, no hidden blur events between digits.

Four numbers worth memorising

Everything on this page reduces to four numbers. Seven is how many patterns the cascade tries. Sixty is the default poll window in seconds. Three is the poll interval. One is the number of evaluate calls needed to fill every digit in a split-input OTP form. Count these against any competing guide on this keyword and see how many are named.

How the whole flow fits together

Three inputs, one agent loop, four outputs. The left side is what the reader controls; the middle is the Assrt runtime (18-tool closed set); the right is what lands in your repo and your CI after a pass.

Forms that break a per-field .fill loop

Every component library in the chip row below installs its OTP splitter on onPaste. Every one of them is broken by a naive per-field type loop. Every one of them accepts a single ClipboardEvent dispatched on the parent. If your app uses any of these, the trick from the previous section is the difference between a green suite and a flake you chase for a week.

Naive per-field fill vs ClipboardEvent

Left tab: the Playwright code a reasonable engineer writes first. It works against a plain text input, but breaks against every library on the chip row above. Right tab: the two-line evaluate that actually ships with Assrt.

What a real run looks like in the terminal

The trace below is an actual OTP scenario run against a local dev server. Note the regex that matched (pattern 1: the labelled code: form), the detection of six split inputs, and the single evaluate call that fills them. Total time, eleven seconds, most of it spent waiting on email delivery.

What Assrt emits as committable Playwright

The English scenario.md becomes real Playwright code you can commit. No proprietary YAML, no vendor DSL, no per-run account tokens. The extract below is what a graduated spec looks like once the runtime refs are resolved to role+name queries and the evaluate call is inlined.

The magic link trap, and how to avoid it

Magic links are a second-order OTP: the code is a URL, and the URL is usually consume-on-GET. Two things go wrong in naive test setups. First, clicking the link inside the email client opens a new browser context and the Playwright session is lost. Second, if the test retries (network flake, slow assertion) the second GET invalidates the session because the token has already been spent. The fix is the same shape as OTP code extraction: the waitForVerificationCode return payload contains body (the first 5000 chars of the cleaned email), you run a URL regex against it, and then call page.goto(url) in the same Playwright context. One visit, one session, no cross-tab loss. Retries have to happen above the waitForVerificationCode call so each retry gets a fresh token in a fresh email.

What this page is not trying to be

Not a philosophy of passwordless auth. Not a comparison of OTP vs magic link as a UX pattern (Scalekit and JumpCloud already rank for that and are fine). This is the part of the problem that stops being written about two clicks into the SERP: the regex that actually runs against real emails, and the one-line dispatch that gets past every modern OTP form. Copy the code, ignore the product, and your own Playwright tests will get more reliable tonight. Or install Assrt and get it for free on top of the rest of the 18-tool agent.