Mailyo

Posted on Oct 2

How to Test Email Verification in Playwright

Email verification is a common part of modern web applications.

A typical registration flow looks like this:

User signs up
    ↓
Verification email is sent
    ↓
User opens email
    ↓
User clicks verification link
    ↓
Account becomes verified

Manually testing this flow works, but it becomes repetitive when you're running the same test dozens or hundreds of times.

That's where browser automation tools such as Playwright can help.

What Should the Test Verify?

A basic Playwright test should confirm that:

A user can register successfully
A verification email is generated
The email reaches the expected inbox
The verification link works
The account changes to a verified state
Invalid or expired links are handled correctly

The goal isn't simply to check that an email was sent. You want to test the complete user journey.

The Basic Playwright Flow

A simplified automated test could look like this:

import { test, expect } from '@playwright/test';

test('user can verify their email', async ({ page }) => {
  await page.goto('https://example.com/signup');

  await page.getByLabel('Email').fill('test@example.com');
  await page.getByLabel('Password').fill('TestPassword123');

  await page.getByRole('button', { name: 'Create account' }).click();

  await expect(
    page.getByText('Check your email')
  ).toBeVisible();
});

This verifies the registration side of the process.

But there's still an important question:

Did the verification email actually arrive?

Testing the Email Side

For a complete end-to-end test, your test environment needs access to the email generated by the application.

There are several ways to approach this.

Option 1: Dedicated Test Mailbox

Create a mailbox specifically for automated testing.

This provides a controlled environment and is usually a good choice for stable CI/CD tests.

Option 2: Email Testing Service

An email-testing service can capture outgoing messages without sending them to real users.

This can be useful when you need to inspect:

Email HTML
Subject lines
Links
Headers
Attachments
Delivery behavior

Option 3: Temporary Email

For manual or short-lived testing, a temporary email address can be convenient.

For example, you can generate a temporary address with Mailyo, use it during registration, and check whether the verification email arrives.

This approach can be useful when you're testing a website manually and don't want to use your personal inbox.

However, public temporary inboxes aren't necessarily appropriate for automated production test infrastructure.

Extracting a Verification Link

Once your test system can access the email, the next step is to extract the verification URL.

Conceptually:

const email = await getLatestTestEmail();

const verificationLink = extractVerificationLink(
  email.body
);

await page.goto(verificationLink);

await expect(
  page.getByText('Email verified')
).toBeVisible();

The exact implementation depends on your email-testing infrastructure.

The important part is keeping the browser test and email retrieval process reliable.

Test More Than Successful Verification

A common mistake is testing only the happy path.

Your application should also handle unusual situations.

Expired Link

What happens when the user clicks an expired verification link?

Expected behavior might be:

Verification link expired
        ↓
Show helpful message
        ↓
Offer "Send new link"

Invalid Link

Try changing part of the verification URL.

The application should reject the request rather than verifying the account.

Multiple Verification Emails

Request verification several times.

Make sure your application has a clearly defined behavior for old and new links.

Already Verified Account

Try opening a verification link after the account has already been verified.

The application should handle this gracefully.

Avoid Hard-Coded Test Accounts

Don't build your test around one permanent account if you can avoid it.

For example, this can become problematic:

const email = 'playwright-test@example.com';

After many test runs, you may have:

Existing accounts
Used verification links
Conflicting database records
Duplicate-email errors

Instead, generate unique test data when appropriate:

const email =
  `test-${Date.now()}@example.test`;

Your test environment can then treat every execution as a fresh registration.

Keep Test Email Separate

It's a good practice to separate testing email from personal and production email.

A useful environment might look like:

Production
    ↓
Real users
    ↓
Production email system

Testing
    ↓
Automated tests
    ↓
Test email system

This separation reduces the risk of test messages reaching real users.

Temporary Email Isn't a Replacement for Test Infrastructure

Temporary email can be useful, but it shouldn't automatically become your entire email-testing strategy.

For serious automated testing, consider using:

A dedicated test mailbox
An email sandbox
Local SMTP testing
A test email API
A staging email environment

Use temporary email where it makes sense, particularly for short-lived manual testing and low-risk registration tests.

A Practical Playwright Testing Strategy

A reasonable testing setup might be:

Local development

Use a local email catcher or SMTP testing tool.

Manual QA

Use a dedicated test mailbox or temporary email address.

CI/CD

Use deterministic email-testing infrastructure that your automated tests can reliably query.

Production

Never use test accounts or temporary inboxes to interact with real customer data.

This keeps each environment predictable.

Final Thoughts

Playwright makes it relatively easy to automate the browser portion of email verification testing.

The harder part is connecting your automated test to the email system.

For manual testing, a temporary email service such as Mailyo can provide a quick way to test registration and verification without filling your personal inbox.

For automated CI/CD testing, however, a dedicated test email system will usually provide more control and reliability.

The best setup depends on whether you're testing manually, locally, or as part of a continuous integration pipeline.

The important thing is to test the entire verification journey, not just the signup button.

DEV Community