Testing OTP email flows shouldn't be flaky — meet AssertKit

The single most flake-prone test in any E2E suite is "user signs up,

verifies via emailed OTP, completes onboarding." Why? Because the email

is async, the test runner can't see it, and the bridge between the two

is a 60-line polling helper everyone writes once and nobody wants to

maintain.

I shipped AssertKit to remove that bridge entirely.

The pitch in 8 lines of test code:

  import { test } from "@assertkit/playwright";



  test("signup with OTP", async ({ page, inbox }) => {

    await page.goto("/signup");

    await page.getByLabel("Email").fill(inbox.address);

    await page.getByRole("button", { name: "Sign up" }).click();

    const otp = await inbox.waitForOtp({ from: "noreply" });

    await page.getByLabel("Code").fill(otp);

  });

That's it. No polling. No regex. No flake.

How it works

1. The inbox fixture gives every test a unique disposable address
   (
   
   
   

   The demo opens a real long-poll against the real wait endpoint. A
   
   canned email arrives 3 seconds later. You'll see the OTP land in real
   
   time.

   
   
   

   Free to try:

   
   
   
   
   
   • Both npm packages are MIT, zero runtime deps
   
   
   • The free public API works without an account
   
   
   • Subscriptions aren't open yet — there's a /beta program for early
     access with admin approval
   
   
   
   
   

   Tech stack (if anyone's curious): Next.js 16 App Router, Drizzle +
   
   Neon Postgres, Supabase Realtime for sub-100ms broadcast, CloudMailin
   
   for inbound MX, Resend for outbound (DKIM-signed), Upstash KV for
   
   rate limits, argon2id + RFC 6238 TOTP for auth.

   
   
   

   Solo founder, happy to answer anything.

   Vollständiger Original-Artikel

   Den kompletten Beitrag mit allen Details direkt auf dev.to lesen.

   ↗ Original-Artikel auf dev.to lesen