DEV Community: zerodrop

Testing NextAuth Magic Links in Playwright Without a Local SMTP Server

zerodrop — Fri, 03 Jul 2026 18:12:43 +0000

The most common approach to testing NextAuth magic links in Playwright looks like this:

import smtpTester from 'smtp-tester';
import { load as cheerioLoad } from 'cheerio';

test.beforeAll(() => {
  mailServer = smtpTester.init(4025);
});

test('magic link login', async ({ page }) => {
  // ...
  const { email } = await mailServer.captureOne('test@example.com', { wait: 1000 });
  const $ = cheerioLoad(email.html);
  const emailLink = $('#magic-link').attr('href');
  await page.goto(emailLink);
});

This requires:

A local SMTP server running as a test fixture
Cheerio to parse the HTML email body
A hardcoded email address shared across tests
A local Next.js app pointing at localhost:4025

None of this works in CI without significant setup. And the Cheerio parsing breaks the moment NextAuth changes its email template.

There's a simpler way.

NextAuth Email Provider + ZeroDrop

ZeroDrop catches emails at Cloudflare's edge. email.magicLink is auto-extracted before your test reads it — no Cheerio, no HTML parsing, no local SMTP server.

const email = await mail.waitForLatest(inbox, { timeout: 15000 });
await page.goto(email.magicLink!);

That's the entire email handling. No parser. No fixture server.

Setup

npm install zerodrop-client @playwright/test

No API key. No signup. No environment variables for ZeroDrop.

NextAuth config

Standard NextAuth Email Provider setup with Resend (or any provider):

// app/api/auth/[...nextauth]/route.ts
import NextAuth from "next-auth";
import Resend from "next-auth/providers/resend";
import { PrismaAdapter } from "@auth/prisma-adapter";
import { prisma } from "@/lib/prisma";

const handler = NextAuth({
  adapter: PrismaAdapter(prisma),
  providers: [
    Resend({
      from: "noreply@yourdomain.com",
    }),
  ],
  pages: {
    signIn: "/login",
    verifyRequest: "/check-email",
  },
});

export { handler as GET, handler as POST };

Testing magic link sign-in

import { test, expect } from "@playwright/test";
import { ZeroDrop } from "zerodrop-client";

const mail = new ZeroDrop();

test("NextAuth magic link sign-in", async ({ page }) => {
  // Generate a unique inbox — no network request
  const inbox = mail.generateInbox();

  // Request a magic link
  await page.goto("/login");
  await page.fill('input[name="email"]', inbox);
  await page.click('button[type="submit"]');

  // NextAuth redirects to verify request page
  await expect(page).toHaveURL("/check-email");

  // ZeroDrop catches the magic link email at the edge
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { hasMagicLink: true },
  });

  // magicLink auto-extracted — no Cheerio, no regex, no HTML parsing
  expect(email.magicLink).toBeTruthy();
  expect(email.magicLink).toContain('/api/auth/callback/resend');

  // Navigate to the magic link — NextAuth creates the session
  await page.goto(email.magicLink!);

  // Assert user is signed in
  await expect(page).toHaveURL("/dashboard");
  await expect(page.locator('text=Sign out')).toBeVisible();
});

Testing that the magic link is single-use

NextAuth invalidates magic link tokens after first use. Test that:

test("magic link is single-use", async ({ page, context }) => {
  const inbox = mail.generateInbox();

  await page.goto("/login");
  await page.fill('input[name="email"]', inbox);
  await page.click('button[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });
  const magicLink = email.magicLink!;

  // First use — should sign in successfully
  await page.goto(magicLink);
  await expect(page).toHaveURL("/dashboard");

  // Second use — token already consumed, should show error
  const page2 = await context.newPage();
  await page2.goto(magicLink);

  // NextAuth shows an error page for invalid/consumed tokens
  await expect(page2.locator('text=Sign in')).toBeVisible();
  await expect(page2).not.toHaveURL("/dashboard");
});

Testing magic link expiry

NextAuth tokens expire after 24 hours by default. Test that expired tokens are rejected:

test("expired magic link is rejected", async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto("/login");
  await page.fill('input[name="email"]', inbox);
  await page.click('button[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Tamper with the token to simulate expiry
  const expiredLink = email.magicLink!.replace(
    /token=[^&]+/,
    'token=expired-token-xyz'
  );

  await page.goto(expiredLink);

  // NextAuth shows an error for invalid tokens
  await expect(page.locator('text=Sign in')).toBeVisible();
});

Filtering when multiple emails land

If your app sends a welcome email alongside the magic link, filter to get the right one:

const email = await mail.waitForLatest(inbox, {
  timeout: 15000,
  filter: {
    from: 'noreply@yourdomain.com',
    subject: 'Sign in',
    hasMagicLink: true,
  },
});

All string filters are case-insensitive partial matches.

Why not use smtp-tester?

The standard smtp-tester approach has several problems in CI:

1. Requires reconfiguring NextAuth for tests

NextAuth needs to point at localhost:4025 in test mode. That means different config for test vs production — a gap that can hide real email delivery bugs.

2. Cheerio parsing breaks with template changes

$('#magic-link').attr('href') assumes a specific HTML structure. NextAuth occasionally changes its email template. When it does, your test silently returns undefined and fails in confusing ways.

3. Shared inbox causes race conditions

test@example.com is shared across all tests. Parallel runs pollute each other's inboxes.

4. Doesn't work in GitHub Actions without Docker

smtp-tester binds to a local port. In CI, NextAuth can't reach it unless you set up Docker networking or run everything in the same container.

ZeroDrop has none of these problems. NextAuth sends to a real ZeroDrop inbox. The email is caught at the edge. email.magicLink is there when your test reads it.

Parallel test runs — no collisions

generateInbox() runs locally with no network request. Each worker gets a unique inbox automatically:

test.describe.configure({ mode: "parallel" });

test("user A login", async ({ page }) => {
  const inbox = mail.generateInbox(); // unique inbox
  // ...
});

test("user B login", async ({ page }) => {
  const inbox = mail.generateInbox(); // different inbox, no collision
  // ...
});

GitHub Actions CI

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
    env:
      NEXTAUTH_SECRET: ${{ secrets.NEXTAUTH_SECRET }}
      NEXTAUTH_URL: ${{ secrets.NEXTAUTH_URL }}
      RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}

No services: block. No SMTP config. No Docker. ZeroDrop catches emails from wherever NextAuth sends them.

Auth.js v5 (NextAuth v5)

The same pattern works with Auth.js v5:

// auth.ts
import NextAuth from "next-auth";
import Resend from "next-auth/providers/resend";

export const { handlers, auth, signIn, signOut } = NextAuth({
  providers: [Resend({ from: "noreply@yourdomain.com" })],
});

// test
test("Auth.js magic link", async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto("/login");
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Auth.js callback URL pattern
  expect(email.magicLink).toContain('/api/auth/callback/resend');

  await page.goto(email.magicLink!);
  await expect(page).toHaveURL("/dashboard");
});

Conclusion

Testing NextAuth magic links doesn't require a local SMTP server, Cheerio, or a hardcoded test email address.

ZeroDrop catches the real email NextAuth sends, email.magicLink is auto-extracted at Cloudflare's edge, and your test navigates to it. No parser. No fixture. No Docker.

Free to use. No signup required. Works in CI out of the box.

→ zerodrop.dev · npm · docs

How to Test Clerk Email Verification in Playwright Without Hitting the 100 Email Limit

zerodrop — Fri, 03 Jul 2026 18:05:19 +0000

Clerk's development mode limits you to 100 emails per calendar month. Once you hit that limit, OTP emails stop being delivered and your tests break.

The official workaround is to use Clerk's reserved test email addresses — fixed emails with hardcoded OTP codes like +clerk_test suffixes. They work, but they mean you're not testing the real email flow. You're testing a bypass.

If you want to test the actual email your users receive — real OTP codes, real magic links, real delivery — you need a different approach.

The problem with Clerk's test mode

Clerk's testing documentation recommends two approaches:

Testing Tokens — bypass email verification entirely using @clerk/testing/playwright
Reserved test emails — use fake addresses with hardcoded OTP codes

Both approaches skip the email delivery. Your Playwright test never sees a real email, never reads a real OTP, never clicks a real magic link.

That means:

If your email template breaks, your tests won't catch it
If Clerk's email delivery goes down, your tests still pass
If the OTP extraction logic changes, you won't know

The only way to catch email delivery problems is to test real email delivery.

The setup: Clerk + ZeroDrop

ZeroDrop gives you disposable email inboxes caught at Cloudflare's edge. Send a real Clerk email to a ZeroDrop inbox. Read email.otp or email.magicLink — auto-extracted, no regex.

No fake email addresses. No hardcoded codes. Real emails, real delivery, every test.

npm install zerodrop-client @clerk/nextjs

Testing Clerk email verification on signup

Clerk's signup flow sends a verification code to the user's email. Here's how to test it end to end:

import { test, expect } from "@playwright/test";
import { ZeroDrop } from "zerodrop-client";

const mail = new ZeroDrop();

test("Clerk email verification on signup", async ({ page }) => {
  // Generate a unique inbox — no network request
  const inbox = mail.generateInbox();

  // Sign up with the ZeroDrop inbox
  await page.goto("/sign-up");
  await page.fill('input[name="emailAddress"]', inbox);
  await page.fill('input[name="password"]', "TestPassword123!");
  await page.click('button[type="submit"]');

  // Clerk sends the verification email
  // ZeroDrop catches it at Cloudflare's edge in <1s
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { hasOtp: true },
  });

  // email.otp is auto-extracted — no regex needed
  expect(email.otp).toBeTruthy();
  expect(email.otp).toMatch(/^\d{6}$/);

  // Clerk renders individual digit inputs
  // Fill the first input — Clerk auto-advances through the rest
  await page.locator('input[name="code-0"]').waitFor();
  await page.fill('input[name="code-0"]', email.otp!);

  // Assert the user is verified and signed in
  await expect(page).toHaveURL("/dashboard");
});

The Clerk OTP input pattern

Clerk renders OTP inputs as individual digit fields — code-0 through code-5. Filling code-0 with all 6 digits triggers auto-advance through the rest:

// Clerk's digit input pattern
await page.locator('input[name="code-0"]').waitFor();
await page.fill('input[name="code-0"]', email.otp!);
// Clerk auto-advances through code-1, code-2, code-3, code-4, code-5

No need to fill each input individually.

Testing Clerk magic link sign-in

If you're using Clerk's passwordless magic link flow:

test("Clerk magic link sign-in", async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto("/sign-in");

  // Switch to email link strategy
  await page.click('button:has-text("Email link")');
  await page.fill('input[name="emailAddress"]', inbox);
  await page.click('button[type="submit"]');

  // Wait for Clerk's magic link email
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { hasMagicLink: true },
  });

  // email.magicLink auto-extracted
  expect(email.magicLink).toBeTruthy();

  // Navigate to the magic link — Clerk signs the user in
  await page.goto(email.magicLink!);

  await expect(page).toHaveURL("/dashboard");
});

Testing Clerk password reset

test("Clerk password reset flow", async ({ page }) => {
  const inbox = mail.generateInbox();

  // First create the user
  // (or use an existing test account)

  // Request password reset
  await page.goto("/sign-in");
  await page.click('button:has-text("Forgot password")');
  await page.fill('input[name="emailAddress"]', inbox);
  await page.click('button[type="submit"]');

  // Catch the reset email
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { hasOtp: true },
  });

  expect(email.otp).toBeTruthy();

  // Enter the reset code
  await page.locator('input[name="code-0"]').waitFor();
  await page.fill('input[name="code-0"]', email.otp!);

  // Set new password
  await page.fill('input[name="newPassword"]', "NewPassword123!");
  await page.fill('input[name="newPasswordConfirmation"]', "NewPassword123!");
  await page.click('button[type="submit"]');

  await expect(page).toHaveURL("/dashboard");
});

Why not use Clerk's Testing Tokens?

Clerk's @clerk/testing/playwright package and Testing Tokens are great for testing authenticated flows — pages that require a signed-in user. They bypass the entire auth flow so you can start tests with a pre-authenticated state.

But they don't test the email flow itself. If you want to verify that:

The verification email is actually sent
The OTP code is correct and extractable
The magic link works end to end
The email template renders correctly

You need to test with real emails. ZeroDrop and Clerk's Testing Tokens are complementary — use Testing Tokens for authenticated page tests, use ZeroDrop for email flow tests.

Avoiding the 100 email limit

Clerk's 100 email/month limit applies to your development instance. ZeroDrop helps you stay under it by:

Running email flow tests separately — not on every commit, but on a dedicated schedule or before releases
Using Clerk's Testing Tokens for authenticated page tests — no email sent, doesn't count toward the limit
Switching to a paid Clerk plan — removes the limit entirely for production testing

For most teams, the pattern is: Testing Tokens for 95% of tests, ZeroDrop for the email flow tests that actually need to verify delivery.

Parallel test runs

generateInbox() runs locally with no network request. Each parallel worker gets a unique inbox:

test.describe.configure({ mode: "parallel" });

test("user A signup", async ({ page }) => {
  const inbox = mail.generateInbox(); // unique per worker
  // ...
});

test("user B signup", async ({ page }) => {
  const inbox = mail.generateInbox(); // different inbox, no collision
  // ...
});

GitHub Actions CI

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
    env:
      NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY: ${{ secrets.CLERK_PUBLISHABLE_KEY }}
      CLERK_SECRET_KEY: ${{ secrets.CLERK_SECRET_KEY }}

ZeroDrop needs no environment variables. No API key, no signup.

What gets auto-extracted

ZeroDrop detects OTP codes near labels like code, verification, otp, pin in the email body. For Clerk emails, this includes:

Sign-up verification codes
Sign-in email codes
Password reset codes

email.otp is a plain string — ready to paste into page.fill().

const email = await mail.waitForLatest(inbox);
email.otp // "847291" — 6-digit Clerk verification code

Conclusion

Clerk's test mode is useful, but it trades real email testing for convenience. Testing Tokens skip email delivery entirely. Reserved test emails use hardcoded codes that never change.

If your Clerk app sends verification emails to real users, test with real emails. ZeroDrop catches them, extracts the OTP, and your test reads email.otp — no regex, no fake addresses, no 100-email-limit anxiety.

Free to use. No signup required. Works in CI out of the box.

→ zerodrop.dev · npm · docs

How to Test Better Auth Email Verification with Playwright

zerodrop — Mon, 29 Jun 2026 20:36:55 +0000

Better Auth has become the go-to TypeScript authentication framework — email verification, magic links, OTP, password reset, all built in. But testing those email flows in CI is a problem nobody talks about.

Your app sends a verification email. Your Playwright test needs to read it, click the link, and assert the user is verified. Without a way to catch that email, you're either mocking it or skipping it entirely.

This guide shows how to test all four Better Auth email flows end to end with Playwright and ZeroDrop — no Docker, no shared inboxes, no regex.

The four flows we're testing

Better Auth ships these email flows out of the box:

Email verification — link sent on signup via emailVerification
Magic link — passwordless login via the magicLink plugin
Email OTP — code-based login/verification via the emailOTP plugin
Password reset — reset link via sendResetPassword

Every one of them sends a real email. Every one of them needs a real inbox to test properly.

Setup

Install the dependencies:

npm install zerodrop-client @playwright/test
npx playwright install chromium

No API key needed for ZeroDrop. No signup. No environment variables.

Better Auth config

Here's the full Better Auth setup with all four email flows:

// app/lib/auth.ts
import { betterAuth } from "better-auth";
import { magicLink } from "better-auth/plugins";
import { emailOTP } from "better-auth/plugins";

export const auth = betterAuth({
  emailAndPassword: {
    enabled: true,
    sendResetPassword: async ({ user, url }) => {
      // Send via your email provider (Resend, Postmark, etc.)
      await sendEmail({ to: user.email, subject: "Reset your password", text: url });
    },
  },

  emailVerification: {
    sendOnSignUp: true,
    sendVerificationEmail: async ({ user, url }) => {
      await sendEmail({ to: user.email, subject: "Verify your email", text: url });
    },
  },

  plugins: [
    magicLink({
      sendMagicLink: async ({ email, url }) => {
        await sendEmail({ to: email, subject: "Your magic link", text: url });
      },
    }),

    emailOTP({
      async sendVerificationOTP({ email, otp, type }) {
        await sendEmail({ to: email, subject: "Your verification code", text: `Your code: ${otp}` });
      },
    }),
  ],
});

Testing email verification on signup

Better Auth sends a verification link when a user signs up. ZeroDrop catches it, email.magicLink is auto-extracted:

import { test, expect } from "@playwright/test";
import { ZeroDrop } from "zerodrop-client";

const mail = new ZeroDrop();

test("email verification on signup", async ({ page }) => {
  const inbox = mail.generateInbox();

  // Sign up with a ZeroDrop inbox
  await page.goto("/signup");
  await page.fill('[name="email"]', inbox);
  await page.fill('[name="password"]', "TestPassword123!");
  await page.click('[type="submit"]');

  // Better Auth shows "check your email" page
  await expect(page.locator("text=Check your email")).toBeVisible();

  // Wait for the verification email — arrives in <1s
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { subject: "Verify" },
  });

  // magicLink auto-extracted — no regex needed
  expect(email.magicLink).toBeTruthy();

  // Navigate to the verification link
  await page.goto(email.magicLink!);

  // Better Auth verifies the user and redirects
  await expect(page).toHaveURL("/dashboard");
});

Testing magic link login

test("magic link login", async ({ page }) => {
  const inbox = mail.generateInbox();

  // Request a magic link
  await page.goto("/login");
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send magic link")');

  await expect(page.locator("text=Magic link sent")).toBeVisible();

  // Catch the email
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { hasMagicLink: true },
  });

  expect(email.magicLink).toBeTruthy();

  // Navigate to the magic link — Better Auth signs the user in
  await page.goto(email.magicLink!);
  await expect(page).toHaveURL("/dashboard");
});

test("magic link is single-use", async ({ page, context }) => {
  const inbox = mail.generateInbox();

  await page.goto("/login");
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send magic link")');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });
  const magicLink = email.magicLink!;

  // First use — succeeds
  await page.goto(magicLink);
  await expect(page).toHaveURL("/dashboard");

  // Second use — Better Auth rejects the consumed token
  const page2 = await context.newPage();
  await page2.goto(magicLink);
  await expect(page2.locator(".error-message")).toBeVisible();
});

Testing email OTP

Better Auth's emailOTP plugin sends a 6-digit code. email.otp is auto-extracted — no regex:

test("email OTP sign-in", async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto("/login");
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send code")');

  await expect(page.locator("text=Code sent")).toBeVisible();

  // OTP auto-extracted at Cloudflare's edge
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { hasOtp: true },
  });

  expect(email.otp).toBeTruthy();
  expect(email.otp).toMatch(/^\d{6}$/);

  // Enter the code
  await page.fill('[name="otp"]', email.otp!);
  await page.click('[type="submit"]');

  await expect(page).toHaveURL("/dashboard");
});

Testing password reset

test("password reset via email link", async ({ page }) => {
  const inbox = mail.generateInbox();

  // Request a password reset
  await page.goto("/forgot-password");
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // Catch the reset email
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: { subject: "Reset" },
  });

  expect(email.magicLink).toBeTruthy();

  // Navigate to the reset link
  await page.goto(email.magicLink!);

  // Set new password
  await page.fill('[name="password"]', "NewPassword123!");
  await page.fill('[name="confirmPassword"]', "NewPassword123!");
  await page.click('[type="submit"]');

  await expect(page.locator("text=Password updated")).toBeVisible();
});

test("reset link is single-use", async ({ page, context }) => {
  const inbox = mail.generateInbox();

  await page.goto("/forgot-password");
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });
  const resetLink = email.magicLink!;

  // First use — succeeds
  await page.goto(resetLink);
  await page.fill('[name="password"]', "NewPassword123!");
  await page.click('[type="submit"]');
  await expect(page.locator("text=Password updated")).toBeVisible();

  // Second use — Better Auth rejects the consumed token
  const page2 = await context.newPage();
  await page2.goto(resetLink);
  await expect(page2.locator(".error-message")).toBeVisible();
});

Parallel test runs — no collisions

generateInbox() runs locally with no network request. Each parallel worker gets a unique inbox automatically:

test.describe.configure({ mode: "parallel" });

test("user A signup", async ({ page }) => {
  const inbox = mail.generateInbox(); // unique per worker
  // ...
});

test("user B signup", async ({ page }) => {
  const inbox = mail.generateInbox(); // different inbox, no collision
  // ...
});

10 parallel workers. 10 isolated inboxes. Zero race conditions.

GitHub Actions CI

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
    env:
      BETTER_AUTH_SECRET: ${{ secrets.BETTER_AUTH_SECRET }}
      RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}

No Docker. No SMTP service. ZeroDrop works out of the box.

How email.otp and email.magicLink work

ZeroDrop catches emails at Cloudflare's edge before storing them. When a Better Auth email arrives, the worker extracts:

email.otp — 4-8 digit numeric code found near labels like code, otp, verification
email.magicLink — URL containing verify, confirm, reset, token, or auth

Both fields are null if not detected. Always assert before using:

expect(email.otp).not.toBeNull();
await page.fill('[name="otp"]', email.otp!);

Working example repo

All four tests are in a working example repo with the full Better Auth + Next.js app:

→ github.com/zerodrop-dev/better-auth-playwright-zerodrop

Clone it, add your .env, and run pnpm test.

Conclusion

Better Auth ships complete email flows out of the box. Testing them end to end doesn't require Docker, shared inboxes, or regex.

email.otp and email.magicLink — auto-extracted at the edge. Your test just reads them.

Free to use. No signup required. Works in CI out of the box.

→ zerodrop.dev · npm · GitHub

How to Test Email Verification Flows in Python with pytest

zerodrop — Fri, 26 Jun 2026 22:07:46 +0000

Testing email verification in Python is one of those problems that looks simple until you actually try it.

Your app sends a verification email. Your pytest test needs to read that email, extract the OTP or magic link, and continue the test. But the email lands in an inbox your test can't reach.

The common workarounds:

Mock the email layer — your tests pass while production email could be broken
Use a shared Gmail inbox — race conditions everywhere in parallel runs
Use MailHog — requires Docker, doesn't test your real email provider
Write regex against the email body — breaks every time the template changes

There's a cleaner way.

The ZeroDrop Approach

ZeroDrop gives you real disposable email inboxes caught at Cloudflare's edge. No Docker. No shared inbox. No regex.

When an email arrives, OTP codes and magic links are auto-extracted before the email is stored. By the time your test calls wait_for_latest(), email.otp and email.magic_link are already there.

email = mail.wait_for_latest(inbox)
email.otp        # "847291" — auto-extracted, no regex
email.magic_link # "https://..." — auto-extracted, no HTML parsing

Setup

pip install zerodrop

No dependencies. No API key. No signup. Python 3.8+.

Basic pytest Example

import pytest
from zerodrop import ZeroDrop

mail = ZeroDrop()

def test_signup_email_verification(page):
    # Generate a unique inbox for this test — no network request
    inbox = mail.generate_inbox()

    # Sign up with the ZeroDrop inbox
    page.goto("/signup")
    page.fill('[name="email"]', inbox)
    page.fill('[name="password"]', "TestPassword123!")
    page.click('[type="submit"]')

    # Wait for the verification email
    email = mail.wait_for_latest(inbox, timeout=15000)

    # OTP is auto-extracted — no regex needed
    assert email.otp is not None
    page.fill('[name="otp"]', email.otp)
    page.click('[type="submit"]')

    assert page.url.endswith("/dashboard")

No helper functions. No regex. No HTML parsing.

pytest Fixtures

For cleaner tests, wrap ZeroDrop in a pytest fixture:

# conftest.py
import pytest
from zerodrop import ZeroDrop

@pytest.fixture(scope="session")
def mail():
    return ZeroDrop()

@pytest.fixture
def inbox(mail):
    """Fresh inbox per test — no shared state."""
    return mail.generate_inbox()

Then use them in tests:

# test_auth.py
def test_signup_verification(page, mail, inbox):
    page.goto("/signup")
    page.fill('[name="email"]', inbox)
    page.fill('[name="password"]', "TestPassword123!")
    page.click('[type="submit"]')

    email = mail.wait_for_latest(inbox, timeout=15000)

    assert email.otp is not None
    page.fill('[name="otp"]', email.otp)
    page.click('[type="submit"]')

    assert page.url.endswith("/dashboard")


def test_magic_link_login(page, mail, inbox):
    page.goto("/login")
    page.fill('[name="email"]', inbox)
    page.click('button:text("Send magic link")')

    email = mail.wait_for_latest(inbox, timeout=15000)

    assert email.magic_link is not None
    page.goto(email.magic_link)

    assert page.url.endswith("/dashboard")


def test_password_reset(page, mail, inbox):
    page.goto("/forgot-password")
    page.fill('[name="email"]', inbox)
    page.click('[type="submit"]')

    email = mail.wait_for_latest(inbox, timeout=15000)

    assert email.magic_link is not None
    page.goto(email.magic_link)

    page.fill('[name="password"]', "NewPassword123!")
    page.click('[type="submit"]')

    assert page.locator(".success-message").is_visible()

Email Filtering

When your signup flow sends multiple emails — welcome email, verification email — filter to target the right one:

from zerodrop import ZeroDrop, ZeroDropFilter

mail = ZeroDrop()

def test_signup_otp_only(page, inbox):
    page.goto("/signup")
    page.fill('[name="email"]', inbox)
    page.click('[type="submit"]')

    # Only catch the verification email
    email = mail.wait_for_latest(
        inbox,
        timeout=15000,
        filter_=ZeroDropFilter(
            from_="noreply@yourapp.com",
            has_otp=True,
        )
    )

    assert email.otp is not None
    page.fill('[name="otp"]', email.otp)
    page.click('[type="submit"]')

All string filters are case-insensitive partial matches.

Parallel Test Runs — No Collisions

generate_inbox() runs locally with no network request. Each worker gets a unique inbox automatically:

# pytest.ini or pyproject.toml
# [tool.pytest.ini_options]
# addopts = "-n auto"  # pytest-xdist parallel execution

# Each test gets its own inbox — generate_inbox() is local, instant
def test_user_a(page, mail):
    inbox = mail.generate_inbox()  # unique per test
    # ...

def test_user_b(page, mail):
    inbox = mail.generate_inbox()  # different inbox, zero collision
    # ...

50 parallel workers. 50 isolated inboxes. Zero race conditions.

GitHub Actions CI

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt
      - run: playwright install --with-deps chromium
      - run: pytest tests/e2e/ -v

No Docker. No SMTP service. No API keys in CI secrets. ZeroDrop works out of the box.

Why Not Use MailHog?

MailHog is a local SMTP server that catches emails in development. It works fine locally — but in CI it requires:

A Docker service block in your GitHub Actions YAML
Running against a local app instance, not your real staging environment
Manual OTP extraction via regex on the raw email body

ZeroDrop works against your real staging environment, in real CI, with no infrastructure overhead. email.otp is just there.

	MailHog	ZeroDrop
Docker required	✓	✗
Tests real email provider	✗	✓
OTP auto-extraction	✗	✓
Magic link extraction	✗	✓
Parallel-safe	✗	✓
CI setup	Complex	None

ZeroDropEmail Fields

email.otp        # "123456" — 4-8 digit code, or None
email.magic_link # "https://app.com/verify?token=abc" — or None
email.subject    # "Verify your email"
email.body       # Full plain-text body
email.from_      # Sender address
email.received_at # datetime

Both otp and magic_link are None if not detected. Always assert before using:

assert email.otp is not None
page.fill('[name="otp"]', email.otp)

Conclusion

Testing email verification in Python doesn't require Docker, regex, or a shared inbox. ZeroDrop gives each pytest test a real isolated inbox, with OTP and magic link auto-extracted at the edge.

email.otp is just there. No regex. No HTML parsing. No maintenance.

Free to use. No signup required. Works in CI out of the box.

→ zerodrop.dev · PyPI · GitHub

OTP Verification in Playwright Without Regex

zerodrop — Fri, 26 Jun 2026 21:47:37 +0000

Most guides to OTP testing in Playwright include a function that looks something like this:

function extractOtp(emailBody: string): string {
  const patterns = [
    /\b(\d{6})\b/,
    /code[:\s]+(\d{4,8})/i,
    /verification[:\s]+(\d{4,8})/i,
    /OTP[:\s]+(\d{4,8})/i,
  ];
  for (const pattern of patterns) {
    const match = emailBody.match(pattern);
    if (match) return match[1];
  }
  throw new Error('OTP not found in email body');
}

This function is fragile. It breaks when the email template changes. It returns false positives when the email body contains order IDs or timestamps. It requires you to maintain regex patterns for every email provider your app might use.

There is a better way.

The Problem with Regex OTP Extraction

When your app sends a verification email, the OTP is buried somewhere in the HTML body. To extract it you need to:

Fetch the raw email body
Parse HTML or plain text
Apply regex patterns that match your specific email format
Handle edge cases — 4-digit vs 6-digit codes, codes in tables, codes in buttons

Every time your email provider changes their template, your regex breaks. Every time you add a new auth provider, you write new patterns. It is maintenance overhead that compounds forever.

The right place to extract the OTP is at the infrastructure layer — before the email even reaches your test suite.

How ZeroDrop Extracts OTPs at the Edge

ZeroDrop catches emails at Cloudflare's edge before storing them. When an email arrives, the worker runs OTP detection on the body and stores the result as a structured field alongside the raw email.

By the time your test calls waitForLatest(), the OTP is already extracted and sitting in email.otp. No regex. No HTML parsing. No maintenance.

const email = await mail.waitForLatest(inbox);
email.otp // "847291" — already extracted

Setup

npm install zerodrop-client

No API key. No signup. No environment variables.

Basic OTP Test

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('OTP email verification', async ({ page }) => {
  const inbox = mail.generateInbox();

  // Trigger the OTP email
  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // Wait for the email — OTP auto-extracted, no regex needed
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  expect(email.otp).toBeTruthy();
  expect(email.otp).toMatch(/^\d{4,8}$/);

  // Enter the OTP
  await page.fill('[name="otp"]', email.otp!);
  await page.click('[type="submit"]');

  await expect(page).toHaveURL('/dashboard');
});

That is the complete test. No regex. No helper function. No HTML parsing.

Testing Digit-by-Digit OTP Inputs

Some auth providers — Clerk, Auth0, Supabase — render OTP inputs as individual digit fields. email.otp is a plain string, so splitting it is trivial:

test('digit-by-digit OTP input', async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Split OTP into individual digits
  const digits = email.otp!.split('');

  for (let i = 0; i < digits.length; i++) {
    await page.fill(`[name="otp-${i}"]`, digits[i]);
  }

  await expect(page).toHaveURL('/dashboard');
});

Clerk-Specific Pattern

Clerk renders a single input that accepts all digits at once but advances focus automatically:

test('Clerk OTP verification', async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto('/sign-up');
  await page.fill('input[name="identifier"]', inbox);
  await page.click('button:has-text("Continue")');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Clerk: fill the first digit input, it auto-advances
  await page.locator('input[name="code-0"]').waitFor();
  await page.fill('input[name="code-0"]', email.otp!);

  await expect(page).toHaveURL('/dashboard');
});

Filtering by Sender When Multiple Emails Land

If your signup flow sends multiple emails — welcome email, verification email — use filter to target the right one:

test('OTP from specific sender', async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // Only catch the verification email, not the welcome email
  const email = await mail.waitForLatest(inbox, {
    timeout: 15000,
    filter: {
      from: 'noreply@yourapp.com',
      hasOtp: true,
    }
  });

  await page.fill('[name="otp"]', email.otp!);
  await page.click('[type="submit"]');

  await expect(page).toHaveURL('/dashboard');
});

Password Reset OTP Flow

test('password reset OTP', async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto('/forgot-password');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Navigate to reset page with OTP
  await page.fill('[name="reset-code"]', email.otp!);
  await page.fill('[name="new-password"]', 'NewPassword123!');
  await page.click('[type="submit"]');

  await expect(page.locator('.success-message')).toBeVisible();
});

Parallel Test Runs — No Collisions

generateInbox() runs locally with no network request. Each parallel worker gets a unique inbox automatically:

test.describe.configure({ mode: 'parallel' });

test('user A OTP', async ({ page }) => {
  const inbox = mail.generateInbox(); // unique per worker
  // ...
});

test('user B OTP', async ({ page }) => {
  const inbox = mail.generateInbox(); // different inbox, zero collision
  // ...
});

50 parallel workers. 50 isolated inboxes. Zero race conditions. No shared inbox collisions.

GitHub Actions CI

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

No Docker. No SMTP service. No API keys in CI secrets. ZeroDrop works out of the box with no configuration.

What Gets Auto-Extracted

ZeroDrop detects OTP codes near common labels in the email body:

Labels: code, otp, pin, verification, passcode, token
Format: 4-8 digit numeric sequences
Scope: plain-text body (more reliable than HTML parsing)

email.otp        // "847291" — 4-8 digit code, or null if not detected
email.magicLink  // "https://app.com/verify?token=..." — or null
email.subject    // "Your verification code"
email.body       // Full plain-text body — available if you need it

email.otp is null if no OTP pattern is detected. Always check before using:

expect(email.otp).not.toBeNull();
await page.fill('[name="otp"]', email.otp!);

Conclusion

OTP extraction belongs at the infrastructure layer, not in your test suite. When the extraction happens at the edge — before the email is stored — your tests never need to touch the raw email body.

email.otp is just there. No regex. No helper functions. No maintenance.

Free to use. No signup required. Works in CI out of the box.

→ zerodrop.dev · npm · GitHub Action

How to Test Magic Link Authentication in Playwright (No API Key, No Regex)

zerodrop — Thu, 25 Jun 2026 19:05:02 +0000

Magic links are becoming the default authentication pattern for modern SaaS apps. Passwordless login, email verification, password resets — they all rely on a link sent to an inbox your test can't normally reach.

The Traditional APIs work. But they require an API key, a paid account, and this kind of code to extract the link:

// The old way — manual regex on raw HTML
const link = message.html?.links?.[0]?.href;

There's a cleaner way.

The Problem with Magic Link Testing

When a user clicks "Send magic link," your app generates a signed token and emails it. The test needs to:

Catch the email
Extract the magic link URL
Navigate to it
Assert the user is authenticated

Step 2 is where most teams give up. The link is buried in HTML. You need to parse the email body, find the right <a> tag, extract the href, handle edge cases where the URL is wrapped or truncated.

ZeroDrop does all of that at the edge before the email reaches your test. email.magicLink is just there — ready to use.

Setup

npm install zerodrop-client

No API key. No account. No environment variables.

Basic Magic Link Test

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('magic link login', async ({ page }) => {
  // Generate a unique inbox for this test
  const inbox = mail.generateInbox();

  // Request a magic link
  await page.goto('/login');
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send magic link")');

  // Wait for the email — arrives in under 1 second via SSE
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // magicLink is auto-extracted from the email body — no regex needed
  expect(email.magicLink).toBeTruthy();

  // Navigate to the magic link
  await page.goto(email.magicLink!);

  // Assert the user is now authenticated
  await expect(page).toHaveURL('/dashboard');
  await expect(page.locator('h1')).toContainText('Welcome');
});

That's the complete test. No HTML parsing. No link extraction. No regex.

Testing Password Reset via Magic Link

Password reset flows work the same way — a signed link is emailed to the user:

test('password reset via magic link', async ({ page }) => {
  const inbox = mail.generateInbox();

  // Trigger password reset
  await page.goto('/forgot-password');
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send reset link")');

  // Catch the reset email
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Navigate to the reset link
  await page.goto(email.magicLink!);

  // Set a new password
  await page.fill('[name="password"]', 'NewSecurePassword123!');
  await page.fill('[name="confirmPassword"]', 'NewSecurePassword123!');
  await page.click('[type="submit"]');

  // Assert success
  await expect(page.locator('.success-message')).toBeVisible();
});

Testing Magic Link Expiry

Magic links should expire. Test that too:

test('expired magic link shows error', async ({ page }) => {
  const inbox = mail.generateInbox();

  await page.goto('/login');
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send magic link")');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Tamper with the token to simulate expiry
  const expiredLink = email.magicLink!.replace(/token=[^&]+/, 'token=expired-token-xyz');
  await page.goto(expiredLink);

  // Assert the app handles expired links gracefully
  await expect(page.locator('.error-message')).toContainText('link has expired');
});

Testing One-Time Use

Magic links should be single-use. Here's how to verify that:

test('magic link is single-use', async ({ page, context }) => {
  const inbox = mail.generateInbox();

  await page.goto('/login');
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send magic link")');

  const email = await mail.waitForLatest(inbox, { timeout: 15000 });
  const magicLink = email.magicLink!;

  // First use — should succeed
  await page.goto(magicLink);
  await expect(page).toHaveURL('/dashboard');

  // Second use — should fail
  const page2 = await context.newPage();
  await page2.goto(magicLink);
  await expect(page2.locator('.error-message')).toBeVisible();
});

Parallel Test Runs — No Collisions

Because generateInbox() runs locally with no network request, parallel workers each get a unique inbox automatically:

test.describe.configure({ mode: 'parallel' });

test('user A magic link', async ({ page }) => {
  const inbox = mail.generateInbox(); // unique per worker
  // ...
});

test('user B magic link', async ({ page }) => {
  const inbox = mail.generateInbox(); // different inbox, no collision
  // ...
});

10 parallel workers. 10 isolated inboxes. Zero race conditions.

GitHub Actions CI

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

No Docker. No SMTP service. No API keys in CI secrets.

ZeroDrop vs Traditional APIs for Magic Link Testing

	Traditional APIs	ZeroDrop
Price	$40/mo	Free
API key required	✓	✗
Magic link extraction	Manual regex	Auto-extracted
Setup time	~30 mins	~5 mins
Parallel-safe	✓	✓
CI secrets needed	✓	✗

How magicLink Extraction Works

ZeroDrop parses the raw HTML payload at Cloudflare's edge before storing it. Our worker engines identify authentication patterns (verify, confirm, reset, token, activate) and isolate the primary call-to-action.

The extracted URL is stored as magicLink on the email object. If no matching URL is found, magicLink is null.

const email = await mail.waitForLatest(inbox);

email.magicLink  // "https://app.com/auth/verify?token=abc123xyz"
                 // or null if no magic link detected

Conclusion

Testing magic link authentication doesn't require a paid email testing service, an API key, or manual HTML parsing. ZeroDrop extracts the link automatically at the edge — your test just reads email.magicLink and navigates to it.

Free to use. No signup required. Works in CI out of the box.

Next Steps

🚀 Get Started: Check out the documentation at zerodrop.dev
📦 Install the Package: Grab the client directly on npm
🛠️ Automate CI: Drop the official GitHub Action straight into your workflow.

How to E2E Test Supabase Auth Email Flows in Playwright (No Docker, No InBucket)

zerodrop — Thu, 25 Jun 2026 16:04:42 +0000

If you've tried to test Supabase authentication flows end-to-end in a CI pipeline, you've probably hit the same wall: the email.

Supabase's signup flow sends a verification email. Your Playwright test needs to click that verification link or enter that OTP. But the email lands in... nowhere your test can reach.

The standard advice is to use InBucket — Supabase's local email interceptor. But InBucket requires running Supabase locally via the CLI, which means Docker in CI. That's a Docker service block in your GitHub Actions YAML, slower builds, and a local Supabase instance that drifts from production.

There's a simpler way.

The Problem with Existing Approaches

InBucket / Local Supabase: InBucket is great for local development — it ships with supabase start and catches emails instantly. But it requires Docker, a full local Supabase stack, and doesn't test against your real Supabase project. In CI, that means a Docker service block, slower builds, and a local instance that can drift from production.

Mocking Supabase: You're not testing the real flow. Your tests pass while production auth could be broken.

Database triggers to set predictable OTPs: Clever, but adds complexity and requires direct database access in CI.

Shared Gmail inbox: Race conditions everywhere in parallel test runs.

The ZeroDrop Approach

ZeroDrop gives you real disposable email inboxes caught at Cloudflare's edge. No Docker. No local Supabase. No shared inbox collisions.

You send a real signup to your real Supabase project, using a ZeroDrop inbox as the email address. The verification email arrives in under a second. Your test reads email.otp or email.magicLink — auto-extracted, no regex needed.

Your app → Supabase → sends verification email → ZeroDrop catches it → your test reads email.otp

Setup

Install the SDK:

npm install zerodrop-client

No API key needed. No signup required.

Testing Supabase Email Verification (OTP Flow)

Supabase's default signup flow sends a 6-digit OTP for email verification. Here's how to test it end-to-end:

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('Supabase signup with email verification', async ({ page }) => {
  // Generate a unique inbox for this test run
  const inbox = mail.generateInbox();

  // Navigate to your signup page
  await page.goto('/signup');

  // Fill in the signup form with the ZeroDrop inbox
  await page.fill('[name="email"]', inbox);
  await page.fill('[name="password"]', 'TestPassword123!');
  await page.click('[type="submit"]');

  // Wait for Supabase to send the verification email
  // ZeroDrop catches it at the edge — arrives in under 1 second
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // OTP is auto-extracted — no regex needed
  expect(email.otp).toBeTruthy();

  // Enter the OTP on the verification screen
  await page.fill('[name="otp"]', email.otp!);
  await page.click('[type="submit"]');

  // Verify the user is now authenticated
  await expect(page).toHaveURL('/dashboard');
});

Testing Supabase Magic Link Flow

If you're using Supabase's passwordless magic link auth:

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('Supabase magic link login', async ({ page }) => {
  const inbox = mail.generateInbox();

  // Request a magic link
  await page.goto('/login');
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send magic link")');

  // Catch the magic link email
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // magicLink is auto-extracted from the email body
  expect(email.magicLink).toBeTruthy();

  // Navigate directly to the magic link
  await page.goto(email.magicLink!);

  // User should now be authenticated
  await expect(page).toHaveURL('/dashboard');
});

Testing Password Reset

test('Supabase password reset flow', async ({ page }) => {
  const inbox = mail.generateInbox();

  // First, create a user (or use an existing test account)
  // Then trigger a password reset
  await page.goto('/forgot-password');
  await page.fill('[name="email"]', inbox);
  await page.click('button:has-text("Send reset email")');

  // Catch the reset email
  const email = await mail.waitForLatest(inbox, { timeout: 15000 });

  // Navigate to the reset link
  await page.goto(email.magicLink!);

  // Set a new password
  await page.fill('[name="password"]', 'NewPassword123!');
  await page.fill('[name="confirmPassword"]', 'NewPassword123!');
  await page.click('[type="submit"]');

  await expect(page).toHaveURL('/login');
});

Running in GitHub Actions CI

No Docker required. Add ZeroDrop's GitHub Action to generate isolated inboxes per test run:

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test
    env:
      NEXT_PUBLIC_SUPABASE_URL: ${{ secrets.SUPABASE_URL }}
      NEXT_PUBLIC_SUPABASE_ANON_KEY: ${{ secrets.SUPABASE_ANON_KEY }}

That's it. No supabase start. No Docker service block. ZeroDrop inboxes are generated client-side — no network request, no setup.

Parallel Test Runs — No Collisions

Because generateInbox() creates a unique inbox on every call with no network request, parallel CI runs are safe by default:

// Each worker gets its own inbox — no shared state, no collisions
test.describe.configure({ mode: 'parallel' });

test('user A signup', async ({ page }) => {
  const inbox = mail.generateInbox(); // unique to this test
  // ...
});

test('user B signup', async ({ page }) => {
  const inbox = mail.generateInbox(); // different inbox, zero collision risk
  // ...
});

50 parallel workers. 50 isolated inboxes. Zero race conditions.

InBucket vs ZeroDrop — When to Use Which

InBucket is the right choice for local development — it's built into Supabase's local stack and works great there. ZeroDrop is the right choice for CI pipelines against real Supabase projects.

	InBucket	ZeroDrop
Best for	Local development	CI pipelines
Docker required	✓	✗
Tests real Supabase project	✗	✓
OTP auto-extraction	✗	✓
Magic link auto-extraction	✗	✓
Parallel-safe	✗	✓
CI setup complexity	High	None

Conclusion

Testing Supabase auth flows end-to-end doesn't have to mean running a full local stack. ZeroDrop gives you real email delivery verification against your real Supabase project, with no Docker, no InBucket, and no shared inbox collisions.

email.otp and email.magicLink are auto-extracted at Cloudflare's edge before they reach your test suite. No regex. No HTML parsing. No race conditions.

Free to use. No signup required. Works in CI out of the box.

→ zerodrop.dev · npm · GitHub Action

Claude Code Built My SaaS But Couldn't Verify Signup Emails

zerodrop — Sat, 20 Jun 2026 19:40:01 +0000

I've been building with Claude Code for the past few months. It's genuinely changed how I work — I can ship features in hours that used to take days.

But I hit a wall I didn't expect.

Claude Code built me a complete authentication system. NextAuth, email verification, password reset, the works. Every line of code was correct. The tests passed. The PR looked great.

Then I tried to run the E2E tests in CI.

They failed. Every single one.

The problem

Claude Code can write the code that sends an email. It can write the test that checks if an email was sent. But it cannot actually receive that email, read it, and verify the link works.

Here's what the test looked like:

test('user can verify email after signup', async ({ page }) => {
  await page.goto('/signup');
  await page.fill('[name="email"]', 'test@example.com');
  await page.click('[type="submit"]');

  // ??? how do we get the verification email here?
  const verificationLink = ???;

  await page.goto(verificationLink);
  await expect(page).toHaveURL('/dashboard');
});

Claude Code filled in everything except the part that actually mattered.

It suggested three approaches:

Mock the email service — "intercept the sendEmail call and return the link directly"
Use MailHog — "run a local SMTP server to catch emails"
Check the database — "query the verification_tokens table directly"

All three are wrong for the same reason: they don't test whether the email actually arrives.

Why mocking is lying

When you mock the email service, you're testing this:

Your app → [mock] → test passes

When you should be testing this:

Your app → email provider → real inbox → verification link → test passes

The difference matters. Mocking passes even when:

Your Resend API key has expired
Your email template has a broken link
Your DNS is misconfigured and emails are going to spam
Your email provider is down
Your verification token is being generated incorrectly

I've been burned by all of these in production. A mocked test would have caught none of them.

Why MailHog doesn't work in CI

Claude Code's second suggestion — MailHog — is the traditional answer. And it works locally.

In CI it's a different story:

services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

This adds 15-30 seconds of cold start time to every CI run. Parallel tests share one inbox, which means race conditions. And MailHog hasn't been maintained since 2020 — the Docker image has known vulnerabilities.

More importantly: MailHog doesn't test real email delivery. It's a fake SMTP server that catches outbound emails before they leave your network. You're not testing whether your email actually reaches an inbox — you're testing whether your app can connect to a local port.

The actual solution

The problem I needed to solve was simple: I need a real email address that my CI pipeline can read programmatically.

I built ZeroDrop for this.

import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can verify email after signup', async ({ page }) => {
  // Generate a real, isolated inbox for this test
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // Wait for the real email to arrive — SSE delivery, sub-second
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  // Magic link auto-extracted — no regex
  expect(email.magicLink).not.toBeNull();

  await page.goto(email.magicLink!);
  await expect(page).toHaveURL('/dashboard');
});

This test:

Sends a real email through your actual email provider (Resend, SendGrid, Postmark)
Catches it in a real inbox
Extracts the verification link automatically
Navigates to it and verifies the flow works end-to-end

If your API key expires — the test fails. If your email template has a broken link — the test fails. If your DNS is misconfigured — the test fails. That's the point.

The GitHub Actions setup

- name: Generate test inbox
  id: inbox
  uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

- name: Run E2E tests
  run: npx playwright test
  env:
    TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
    RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}

Each CI run gets a fresh, isolated inbox. Parallel jobs don't share state. No Docker. No cold start. No MailHog.

What this means for AI-built apps

Claude Code is remarkably good at building auth systems. The code it generates is correct, well-structured, and follows best practices. But it has a blind spot: it can't verify that the system actually works end-to-end because it can't interact with the physical world.

Email delivery is part of the physical world. Your email provider, your DNS configuration, your email templates — none of these exist in Claude Code's context window. It can write code that calls the API. It can't verify the email arrives.

This is the infrastructure gap that AI coding tools expose: as agents ship code faster, the verification layer becomes the bottleneck.

ZeroDrop is one piece of that layer — the email piece. The test that Claude Code couldn't write, ZeroDrop makes possible.

The broader pattern

Every auth-enabled app built with an AI coding tool will eventually hit this wall:

Cursor builds the auth flow → tests mock the email → CI is green → production breaks
Claude Code builds the password reset → MailHog catches it locally → CI Docker fails → nobody notices
Devin ships the signup flow → email verification is skipped in tests → token expiry bugs reach users

The pattern is the same: AI builds fast, verification infrastructure hasn't caught up.

The fix isn't to build slower. It's to give your AI agent the infrastructure layer it's missing.

Try it

npm install zerodrop-client

Free tier. No signup. No API key. No Docker.

The test Claude Code couldn't finish — you can finish it in 5 minutes.

→ zerodrop.dev

Testing Email Flows in Cypress Without a Mail Server

zerodrop — Fri, 19 Jun 2026 20:05:02 +0000

Cypress is one of the most popular E2E testing frameworks for web applications. But testing email flows in Cypress has always required either a running mail server or mocking the email layer entirely.

This guide shows how to test real email flows in Cypress — verification emails, OTP codes, magic links, and password resets — without Docker, without MailHog, and without mocking.

The problem with email testing in Cypress

Most Cypress setups for email testing fall into one of three categories:

1. Mock the email service

cy.intercept('POST', '/api/send-email', { statusCode: 200 });

Fast, but tests nothing. If your email template has a broken link, this passes.

2. Use MailHog

services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

Requires Docker in CI, 15-30 seconds cold start, shared inbox breaks parallel tests, unmaintained since 2020.

3. Use a shared Gmail account
OAuth setup, manual cleanup, parallel tests collide. Not CI-friendly.

ZeroDrop replaces all three: real emails, no infrastructure, isolated per test.

Install

npm install zerodrop-client

Basic email verification test

// cypress/e2e/auth.cy.js
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

describe('Email verification', () => {
  it('user can sign up and verify email', () => {
    const inbox = Cypress.env('TEST_INBOX') ?? mail.generateInbox();

    // Sign up with disposable email
    cy.visit('/signup');
    cy.get('[name="email"]').type(inbox);
    cy.get('[name="password"]').type('TestPass123!');
    cy.get('[type="submit"]').click();

    cy.url().should('include', '/check-email');

    // Wait for verification email — magic link auto-extracted
    cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
      .then((email) => {
        expect(email.subject).to.contain('Verify');
        expect(email.magicLink).to.not.be.null;

        // Click the verification link
        cy.visit(email.magicLink);
        cy.url().should('include', '/dashboard');
      });
  });
});

OTP verification

ZeroDrop extracts OTP codes automatically — no regex needed in your tests:

it('OTP login flow', () => {
  const inbox = Cypress.env('TEST_INBOX') ?? mail.generateInbox();

  cy.visit('/login');
  cy.get('[name="email"]').type(inbox);
  cy.get('[type="submit"]').click();

  cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
    .then((email) => {
      // email.otp is auto-extracted at the edge
      expect(email.otp).to.not.be.null;

      cy.get('[name="otp"]').type(email.otp);
      cy.get('[type="submit"]').click();
      cy.url().should('include', '/dashboard');
    });
});

Password reset flow

it('password reset flow', () => {
  const inbox = Cypress.env('TEST_INBOX') ?? mail.generateInbox();

  // Request password reset
  cy.visit('/forgot-password');
  cy.get('[name="email"]').type(inbox);
  cy.get('[type="submit"]').click();

  cy.contains('Check your email').should('be.visible');

  // Catch reset email
  cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
    .then((email) => {
      expect(email.magicLink).to.not.be.null;

      cy.visit(email.magicLink);
      cy.get('[name="password"]').type('NewPass123!');
      cy.get('[type="submit"]').click();
      cy.contains('Password updated').should('be.visible');
    });
});

Parallel tests — zero configuration

Each test generates its own isolated inbox. No shared state, no race conditions:

describe('Parallel email flows', () => {
  it('flow A', () => {
    const inbox = mail.generateInbox(); // unique per test
    // ...
  });

  it('flow B', () => {
    const inbox = mail.generateInbox(); // different inbox
    // ...
  });
});

Run with cypress run --parallel — each spec gets its own inbox automatically.

Cypress custom command

Add a reusable command to your cypress/support/commands.js:

// cypress/support/commands.js
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

Cypress.Commands.add('waitForEmail', (inbox, options = {}) => {
  return cy.wrap(
    mail.waitForLatest(inbox, { timeout: 30000, ...options }),
    { timeout: 35000 }
  );
});

Cypress.Commands.add('generateInbox', () => {
  return cy.wrap(
    Cypress.env('TEST_INBOX') ?? mail.generateInbox()
  );
});

// Usage in tests
it('verifies email', () => {
  cy.generateInbox().then((inbox) => {
    cy.visit('/signup');
    cy.get('[name="email"]').type(inbox);
    cy.get('[type="submit"]').click();

    cy.waitForEmail(inbox).then((email) => {
      cy.visit(email.magicLink);
      cy.url().should('include', '/dashboard');
    });
  });
});

cypress.config.js

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3000',
    defaultCommandTimeout: 10000,
    pageLoadTimeout: 60000,
    env: {
      // TEST_INBOX injected by GitHub Actions
    },
  },
});

GitHub Actions workflow

name: Cypress E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run Cypress tests
        run: npx cypress run
        env:
          CYPRESS_TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          RESEND_API_KEY: ${{ secrets.RESEND_API_KEY }}
          CYPRESS_BASE_URL: ${{ secrets.STAGING_URL }}

The CYPRESS_ prefix automatically makes variables available as Cypress.env('TEST_INBOX').

Replacing MailHog

If you're migrating from MailHog, here's the before and after:

Before — MailHog:

# docker-compose.yml
services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - 1025:1025
      - 8025:8025

// cypress/e2e/auth.cy.js
cy.request('GET', 'http://localhost:8025/api/v2/messages')
  .then((response) => {
    const message = response.body.items[0];
    const link = message.Content.Body.match(/https?:\/\/\S+/)?.[0];
    cy.visit(link);
  });

After — ZeroDrop:

cy.wrap(mail.waitForLatest(inbox, { timeout: 30000 }))
  .then((email) => {
    cy.visit(email.magicLink); // auto-extracted, no regex
  });

No Docker. No service block. No regex. No cold start.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test Amazon SES Email Workflows in Playwright

zerodrop — Fri, 19 Jun 2026 19:53:38 +0000

Amazon SES is the go-to transactional email service for teams already in the AWS ecosystem. But testing SES emails end-to-end in CI is notoriously painful — IAM permissions, sandbox restrictions, and no easy way to catch sent emails programmatically.

This guide shows the complete setup for testing Amazon SES email flows in Playwright using ZeroDrop — no Docker, no shared inboxes, no mocking.

The app we're testing

A Next.js API route that sends a verification email via Amazon SES:

// app/api/auth/signup/route.ts
import { SESClient, SendEmailCommand } from '@aws-sdk/client-ses';

const ses = new SESClient({
  region: process.env.AWS_REGION!,
  credentials: {
    accessKeyId: process.env.AWS_ACCESS_KEY_ID!,
    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY!,
  },
});

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await ses.send(new SendEmailCommand({
    Source: 'noreply@yourapp.com',
    Destination: { ToAddresses: [email] },
    Message: {
      Subject: { Data: 'Verify your email' },
      Body: {
        Html: {
          Data: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
        },
      },
    },
  }));

  return Response.json({ success: true });
}

Stage 1 — Local development: SES sandbox mode

When you first create an Amazon SES account, it starts in sandbox mode. In sandbox mode:

You can only send emails to verified email addresses
You can only send emails from verified email addresses or domains
There's a sending limit of 200 emails per day

This is fine for local development — verify your own email address in the SES console and use it as the test recipient. But sandbox mode completely blocks automated CI testing because you can't verify a randomly generated @zerodrop-sandbox.online address.

What it solves: Basic local testing with a fixed test email address.

What it doesn't solve: Automated testing with random addresses, parallel test runs, or CI pipelines.

Stage 2 — Request production access

To use SES with ZeroDrop in CI, you need to move out of sandbox mode. Request production access in the AWS SES console:

Go to SES → Account dashboard
Click Request production access
Fill in your use case — "transactional email for application testing"
AWS typically approves within 24 hours

Once approved, SES can send to any email address including ZeroDrop inboxes.

Stage 3 — CI: SES production + ZeroDrop

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — SES sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
});

OTP flows

await ses.send(new SendEmailCommand({
  Source: 'noreply@yourapp.com',
  Destination: { ToAddresses: [email] },
  Message: {
    Subject: { Data: 'Your verification code' },
    Body: {
      Html: { Data: `<p>Your code is: <strong>${otp}</strong></p>` },
    },
  },
}));

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted at the edge — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

IAM permissions for CI

Create a dedicated IAM user for CI with minimal permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ses:SendEmail",
        "ses:SendRawEmail"
      ],
      "Resource": "*"
    }
  ]
}

Store AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as GitHub Actions secrets — never in your codebase.

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          AWS_REGION: ${{ secrets.AWS_REGION }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

Pro tip: Use GitHub's OIDC integration with AWS IAM roles instead of long-lived access keys — more secure and no key rotation needed.

The full picture

	SES sandbox (local)	SES production (staging)	SES production + ZeroDrop (CI)
Verified recipients only	✅ (limitation)	❌	❌
Random test addresses	❌	✅	✅
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Request production SES access early — it unlocks automated testing and takes 24 hours to approve. Once approved, the live SES + ZeroDrop combination gives you full E2E coverage in CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to E2E Test Mailgun Email Workflows in Playwright

zerodrop — Fri, 19 Jun 2026 19:51:55 +0000

Mailgun is a popular transactional email API trusted by developers for reliable delivery. But how do you test that your Mailgun emails actually arrive, contain the right content, and work end-to-end in CI?

This guide covers the full testing progression — from local development to automated Playwright tests in GitHub Actions.

The app we're testing

A Next.js API route that sends a verification email via Mailgun:

// app/api/auth/signup/route.ts
import Mailgun from 'mailgun.js';
import FormData from 'form-data';

const mailgun = new Mailgun(FormData);
const mg = mailgun.client({
  username: 'api',
  key: process.env.MAILGUN_API_KEY!,
});

export async function POST(req: Request) {
  const { email } = await req.json();

  const token = crypto.randomUUID();
  const verifyUrl = `${process.env.NEXT_PUBLIC_URL}/verify?token=${token}`;

  await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
    from: 'noreply@yourapp.com',
    to: email,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
  });

  return Response.json({ success: true });
}

Stage 1 — Local development: Mailgun sandbox domain

Mailgun provides a sandbox domain for testing. Emails sent to the sandbox domain are captured in your Mailgun dashboard without being delivered to real inboxes.

const mg = mailgun.client({
  username: 'api',
  key: process.env.MAILGUN_API_KEY!,
});

// Use sandbox domain for local development
await mg.messages.create(
  process.env.NODE_ENV === 'development'
    ? process.env.MAILGUN_SANDBOX_DOMAIN!  // sandbox.mailgun.org
    : process.env.MAILGUN_DOMAIN!,
  {
    from: 'noreply@sandbox.mailgun.org',
    to: email,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify.</p>`,
  }
);

Important: Mailgun's sandbox domain only delivers to pre-authorized recipient email addresses. You must add your test email to the authorized list in your Mailgun dashboard.

What it solves: Visual inspection during local development without sending real emails.

What it doesn't solve: Automated testing. You can't programmatically read emails from Mailgun's dashboard in a Playwright test. The authorized recipient limitation also makes it unsuitable for CI where you need random inbox addresses.

Stage 2 — Staging: Mailgun live domain to a real inbox

Switch to your live Mailgun domain for staging:

await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
  from: 'noreply@yourapp.com',
  to: email,
  subject: 'Verify your email',
  html: `<p>Click <a href="${verifyUrl}">here</a> to verify.</p>`,
});

Emails now go through real delivery. You can manually verify they arrive, links work, and nothing lands in spam.

What it solves: Does the email actually reach a real inbox end-to-end?

What it doesn't solve: Automation. You can't run this in CI without access to a real inbox your test can read.

Stage 3 — CI: Mailgun live domain + ZeroDrop

For automated Playwright tests in GitHub Actions:

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('user can sign up and verify email', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();
  // → "swift-x7k2m@zerodrop-sandbox.online"

  // 2. Sign up — Mailgun sends a real verification email to this inbox
  await page.goto('/signup');
  await page.fill('[data-testid="email"]', inbox);
  await page.click('[data-testid="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);

  // 5. Assert verified
  await expect(page).toHaveURL('/dashboard');
});

No authorized recipient list. No sandbox limitations. ZeroDrop generates a new inbox for every test run — Mailgun delivers to it like any real email address.

OTP flows

await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
  from: 'noreply@yourapp.com',
  to: email,
  subject: 'Your verification code',
  html: `<p>Your code is: <strong>${otp}</strong></p>`,
});

const email = await mail.waitForLatest(inbox, { timeout: 30000 });

// OTP auto-extracted at the edge — no regex needed
expect(email.otp).not.toBeNull();
await page.fill('[data-testid="otp"]', email.otp!);
await page.click('[data-testid="verify"]');

Using Mailgun templates

If you use Mailgun's stored templates:

await mg.messages.create(process.env.MAILGUN_DOMAIN!, {
  from: 'noreply@yourapp.com',
  to: email,
  template: 'verify-email',
  'h:X-Mailgun-Variables': JSON.stringify({
    verify_url: verifyUrl,
    username: 'Test User',
  }),
});

// ZeroDrop catches the fully rendered template
const email = await mail.waitForLatest(inbox, { timeout: 30000 });
expect(email.magicLink).not.toBeNull();

This tests that your Mailgun template renders correctly with real variable substitution.

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          MAILGUN_API_KEY: ${{ secrets.MAILGUN_API_KEY }}
          MAILGUN_DOMAIN: ${{ secrets.MAILGUN_DOMAIN }}
          NEXT_PUBLIC_URL: ${{ secrets.STAGING_URL }}

// Use CI inbox or generate locally
const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

The full picture

	Sandbox domain (local)	Live domain (staging)	Live domain + ZeroDrop (CI)
Visual inspection	✅ dashboard	✅ real inbox	✅ automated
No real emails sent	✅	❌	❌
Authorized recipients only	✅ (limitation)	❌	❌
Automated in CI	❌	❌	✅
Random test addresses	❌	✅	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Use the sandbox during development, the live domain for manual staging verification, and the live domain + ZeroDrop for automated CI.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm

How to Test Nodemailer Email Flows in Playwright

zerodrop — Fri, 19 Jun 2026 19:38:07 +0000

Nodemailer is the most widely used email library in Node.js. If your Express, Next.js, or NestJS app sends emails, there's a good chance it's using Nodemailer under the hood.

But testing those emails end-to-end in CI has always been the hard part. This guide shows how to test the complete email flow with Playwright and ZeroDrop — no Docker, no fake SMTP server, no mocking.

The typical Nodemailer setup

// lib/email.ts
import nodemailer from 'nodemailer';

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT),
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS,
  },
});

export async function sendVerificationEmail(to: string, token: string) {
  const verifyUrl = `${process.env.APP_URL}/verify?token=${token}`;

  await transporter.sendMail({
    from: 'noreply@yourapp.com',
    to,
    subject: 'Verify your email',
    html: `<p>Click <a href="${verifyUrl}">here</a> to verify your email.</p>`,
  });
}

export async function sendPasswordResetEmail(to: string, token: string) {
  const resetUrl = `${process.env.APP_URL}/reset-password?token=${token}`;

  await transporter.sendMail({
    from: 'noreply@yourapp.com',
    to,
    subject: 'Reset your password',
    html: `<p>Click <a href="${resetUrl}">here</a> to reset your password.</p>`,
  });
}

export async function sendOTPEmail(to: string, otp: string) {
  await transporter.sendMail({
    from: 'noreply@yourapp.com',
    to,
    subject: 'Your verification code',
    html: `<p>Your code is: <strong>${otp}</strong></p>`,
  });
}

Stage 1 — Local development: Nodemailer test account

Nodemailer has a built-in test account generator using Ethereal Email:

// For local development only
const testAccount = await nodemailer.createTestAccount();

const transporter = nodemailer.createTransport({
  host: 'smtp.ethereal.email',
  port: 587,
  auth: {
    user: testAccount.user,
    pass: testAccount.pass,
  },
});

// After sending, preview the email
const info = await transporter.sendMail({ ... });
console.log('Preview URL:', nodemailer.getTestMessageUrl(info));

This is useful for inspecting emails locally — the preview URL opens in a browser. But you can't automate reading from Ethereal in a Playwright test, and it doesn't work in CI.

What it solves: Visual inspection during local development.

What it doesn't solve: Automated testing. No programmatic API to read the email in a test.

Stage 2 — CI: Nodemailer + real SMTP + ZeroDrop

For automated testing in GitHub Actions, point Nodemailer at a real SMTP provider (Resend, SendGrid, Postmark) and use ZeroDrop to catch the emails:

npm install zerodrop-client

import { test, expect } from '@playwright/test';
import { ZeroDrop } from 'zerodrop-client';

const mail = new ZeroDrop();

test('email verification flow', async ({ page }) => {
  // 1. Generate a disposable inbox
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

  // 2. Sign up — Nodemailer sends the verification email
  await page.goto('/signup');
  await page.fill('[name="email"]', inbox);
  await page.fill('[name="password"]', 'TestPass123!');
  await page.click('[type="submit"]');

  await expect(page).toHaveURL('/check-email');

  // 3. ZeroDrop catches the email — magic link auto-extracted
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });

  expect(email.subject).toContain('Verify your email');
  expect(email.magicLink).not.toBeNull();

  // 4. Click the verification link
  await page.goto(email.magicLink!);
  await expect(page).toHaveURL('/dashboard');
});

OTP flow

test('OTP login', async ({ page }) => {
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

  await page.goto('/login');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  // OTP auto-extracted at the edge — no regex needed
  const email = await mail.waitForLatest(inbox, { timeout: 30000 });
  expect(email.otp).not.toBeNull();

  await page.fill('[name="otp"]', email.otp!);
  await page.click('[type="submit"]');

  await expect(page).toHaveURL('/dashboard');
});

Password reset flow

test('password reset', async ({ page }) => {
  const inbox = process.env.TEST_INBOX ?? mail.generateInbox();

  await page.goto('/forgot-password');
  await page.fill('[name="email"]', inbox);
  await page.click('[type="submit"]');

  const email = await mail.waitForLatest(inbox, { timeout: 30000 });
  expect(email.magicLink).not.toBeNull();

  await page.goto(email.magicLink!);
  await page.fill('[name="password"]', 'NewPass123!');
  await page.click('[type="submit"]');

  await expect(page.getByText('Password updated')).toBeVisible();
});

Configuring Nodemailer for CI

The key is using a real SMTP provider in CI while keeping Ethereal for local development:

// lib/email.ts
const isCI = process.env.CI === 'true';

const transporter = isCI
  ? nodemailer.createTransport({
      // Real SMTP in CI — emails actually delivered
      host: process.env.SMTP_HOST,      // e.g. smtp.resend.com
      port: 587,
      auth: {
        user: process.env.SMTP_USER,    // e.g. resend
        pass: process.env.SMTP_PASS,    // e.g. your Resend API key
      },
    })
  : nodemailer.createTransport({
      // Ethereal locally — visual inspection only
      host: 'smtp.ethereal.email',
      port: 587,
      auth: {
        user: process.env.ETHEREAL_USER,
        pass: process.env.ETHEREAL_PASS,
      },
    });

Using Resend as the SMTP backend:

SMTP_HOST=smtp.resend.com
SMTP_PORT=587
SMTP_USER=resend
SMTP_PASS=re_your_api_key

Using SendGrid:

SMTP_HOST=smtp.sendgrid.net
SMTP_PORT=587
SMTP_USER=apikey
SMTP_PASS=SG.your_api_key

GitHub Actions workflow

name: E2E Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci

      - run: npx playwright install --with-deps chromium

      - name: Generate test inbox
        id: inbox
        uses: zerodrop-dev/create-inbox@8706a59 # v1.0.0

      - name: Run E2E tests
        run: npx playwright test
        env:
          CI: true
          TEST_INBOX: ${{ steps.inbox.outputs.inbox }}
          SMTP_HOST: smtp.resend.com
          SMTP_PORT: 587
          SMTP_USER: resend
          SMTP_PASS: ${{ secrets.RESEND_API_KEY }}
          APP_URL: ${{ secrets.STAGING_URL }}

The full picture

	Ethereal (local)	Real SMTP (staging)	Real SMTP + ZeroDrop (CI)
Visual inspection	✅ preview URL	✅ real inbox	✅ automated
No real emails sent	✅	❌	❌
Automated in CI	❌	❌	✅
Parallel test runs	❌	❌	✅
OTP auto-extraction	❌	❌	✅
Tests real delivery	❌	✅	✅

Use Ethereal locally for template inspection. Use a real SMTP provider + ZeroDrop in CI for full end-to-end coverage.

Why not use MailHog?

MailHog is the traditional alternative — a fake SMTP server that catches emails locally. The problems:

Requires a running Docker container in CI
Adds 15-30 seconds cold start time per CI run
Parallel tests share one inbox — race conditions when multiple tests send emails simultaneously
Unmaintained since 2020

ZeroDrop solves all three: no Docker, no cold start, and every test gets its own isolated inbox.

ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm