DEV Community: Mailyo

Temporary Email vs Mocking Email: What Should Developers Test?

Mailyo — Fri, 02 Oct 2026 17:57:07 +0000

Email is often one of the most overlooked parts of application testing.

A signup form might work perfectly in the browser, but that doesn't necessarily mean the complete email workflow works correctly.

Your application may need to:

Send verification emails
Deliver OTP codes
Send password-reset links
Confirm email changes
Send account notifications
Handle bounced or invalid addresses

Developers therefore have several ways to test email functionality.

Two common approaches are mocking email and using a real or temporary inbox.

They solve different problems.

What Is Email Mocking?

Email mocking means replacing the real email delivery process with a controlled testing environment.

Instead of sending an email through your normal infrastructure, the application sends the message to a test system where you can inspect it.

For example:

Application
    ↓
Email service
    ↓
Test email server
    ↓
Captured message

Nothing needs to reach a real inbox.

This is useful during development because you can inspect the message without worrying about sending test emails to real users.

What Can You Test With Mocked Email?

Mocking is particularly useful for checking the contents of an email.

You can test:

Subject lines
HTML structure
Plain-text versions
Verification URLs
OTP codes
Dynamic user information
Email templates
Headers
Links and buttons

For example, you might verify that an email contains:

Subject: Verify your account

Hello John,

Please verify your email address.

[Verify Email]

This link expires in 30 minutes.

This type of test can run quickly and repeatedly.

What Does a Temporary Inbox Test?

A temporary inbox approaches the problem from the user's perspective.

Instead of only checking whether your application generated the correct email, you check whether the message can actually reach an inbox.

The flow might be:

Create test account
        ↓
Generate temporary email
        ↓
Submit registration
        ↓
Application sends email
        ↓
Email reaches inbox
        ↓
Open verification message
        ↓
Click verification link

This tests more of the actual user journey.

For low-risk manual testing, a service such as Mailyo can provide a temporary inbox without requiring you to use your personal email address.

These Tests Are Not the Same

One of the most important distinctions is that mocking and real inbox testing answer different questions.

Mocking asks:

“Did my application generate the correct email?”

An inbox-based test asks:

“Can the user actually receive and use the email?”

Both questions can be valuable.

Example: Testing a Verification Email

Imagine your application sends an account verification email.

Mocked test

You could verify:

Email generated
✓ Correct recipient
✓ Correct subject
✓ Correct verification URL
✓ Correct expiration time
✓ Correct HTML

This is fast and deterministic.

Inbox test

You could verify:

Registration completed
✓ Email delivered
✓ Message appears in inbox
✓ Verification link opens
✓ Account becomes verified

This tests a larger portion of the system.

What About OTP Emails?

OTP-based authentication introduces additional cases.

Suppose your application sends:

Your verification code is 482913

You should test more than whether the email exists.

Consider testing:

Correct code
Incorrect code
Expired code
Previously used code
Multiple requested codes
Rate limits
Resending a code
Code length
Numeric versus alphanumeric codes

A mocked email system can make these tests easy to control.

A real inbox test can help verify that the actual delivery flow works.

Why Not Use a Real Personal Inbox?

Using your personal email for automated or repeated testing can become inconvenient very quickly.

You may create dozens of test messages every day.

Your inbox could eventually contain:

Verification email
Password reset
Welcome email
Verification email
Test notification
Password reset
Welcome email
...

It also makes it harder to distinguish development activity from real communication.

For this reason, testing environments should have their own email strategy.

When Should You Use Mocking?

Email mocking is useful when you need:

Fast tests

You don't want every unit or integration test waiting for an external mail provider.

Predictable results

The test environment should behave consistently.

Template testing

You want to inspect generated HTML and content.

CI/CD testing

Automated pipelines benefit from deterministic infrastructure.

Error simulation

You can intentionally simulate delivery failures and other conditions.

When Is an Inbox Test Useful?

An inbox-based test can be useful when you need to verify the complete experience.

For example:

Manual QA

A tester wants to confirm that registration works from beginning to end.

Staging testing

You want to verify that your staging environment can actually deliver emails.

Verification workflows

You need to confirm that links or OTPs work after delivery.

Real-world integration testing

You want to test more than just the email-generation code.

A Combined Testing Strategy

You don't necessarily have to choose one approach.

A strong testing strategy can use both.

For example:

                    Email Tests
                         │
             ┌───────────┴───────────┐
             │                       │
          Mocking                Inbox Test
             │                       │
      Fast automated tests      End-to-end tests
             │                       │
      Template validation       Delivery validation
             │                       │
      Error simulation         User experience

Your unit and integration tests can use mocked email infrastructure.

Your end-to-end tests can use a dedicated testing inbox.

Manual QA can use either a dedicated mailbox or a temporary email address when appropriate.

Don't Forget Email Security

Email testing should also consider security.

Check that:

Verification tokens aren't predictable
Tokens expire correctly
Tokens can't be reused
Password-reset links aren't exposed unnecessarily
Users cannot verify another account
Sensitive information isn't included in email URLs
Expired links are rejected

Temporary email doesn't change these requirements.

It is simply one possible testing input.

What About Mailyo?

For a quick manual test, Mailyo can be used to create a temporary email address and check whether a low-risk registration or verification email arrives.

For example:

Open Mailyo
    ↓
Generate temporary email
    ↓
Use address in test signup
    ↓
Wait for verification email
    ↓
Open message
    ↓
Test verification link

For long-running automated test suites, however, you may want a dedicated email-testing solution with predictable APIs and controlled test data.

Final Thoughts

Mocking email and testing with a real inbox aren't competing techniques.

They test different layers of your application.

Use mocked email when you need fast, predictable tests around email generation and application logic.

Use an inbox-based test when you need to verify delivery and the complete user experience.

For many development teams, combining both approaches provides better coverage than relying on either one alone.

The important question isn't “Which one is better?”

It's:

“Which part of the email workflow am I trying to test?”

How to Test Email Verification in Playwright

Mailyo — Fri, 02 Oct 2026 17:51:10 +0000

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.

How to Test Email Verification Flows Without Using Your Personal Inbox

Mailyo — Fri, 02 Oct 2026 17:45:51 +0000

Email verification is one of those features that looks simple until you have to test it repeatedly.

A typical signup flow might look like this:

User creates an account.
The application sends a verification email.
User opens the email.
User clicks a verification link or enters an OTP.
The account becomes verified.

For developers and QA engineers, testing this flow can quickly fill a personal inbox with test emails.

A temporary email address can be useful for low-risk testing when the service being tested accepts disposable addresses.

Why Use a Separate Email for Testing?

Using your personal email for development and QA testing can create several problems.

You may end up with:

Dozens of verification emails
Password-reset messages
Test account notifications
Marketing emails triggered by test registrations
Multiple accounts associated with the same address
Difficulty finding real messages among test data

A separate testing mailbox solves some of these problems.

For short-lived tests, a temporary inbox can be another option.

A Simple Email Verification Test

Imagine you're testing a new web application.

You want to verify that registration works correctly.

Instead of using your normal email address, generate a temporary email address and enter it into the signup form.

Then:

Open signup page
      ↓
Enter temporary email
      ↓
Create account
      ↓
Application sends verification email
      ↓
Open temporary inbox
      ↓
Read verification email
      ↓
Click verification link
      ↓
Account becomes verified

This gives you a clean email address for the test.

What Should You Test?

Receiving the email is only one part of the process.

A useful QA checklist includes:

1. Email delivery

Check whether the verification email arrives successfully.

2. Correct recipient

Make sure the email is delivered to the address used during registration.

3. Verification link

Click the link and confirm that the application correctly verifies the account.

4. OTP verification

If the application uses a verification code, confirm that the code is correct and accepted.

5. Expired verification links

Test what happens when a verification link has expired.

6. Resend functionality

Request another verification email and make sure the newest message works correctly.

7. Invalid codes

Enter an incorrect OTP and verify that the application displays an appropriate error.

8. Already verified accounts

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

These edge cases often reveal bugs that a basic "email arrived" test won't catch.

Where Temporary Email Can Help

Temporary email is particularly useful for short-lived and low-risk testing scenarios.

For example, you might need to:

Test a registration form
Check email verification
Test an OTP flow
Create a temporary demo account
Verify password-reset functionality
Test whether transactional emails are being sent

Mailyo is one option for generating a temporary email address without using your normal inbox.

However, temporary email isn't appropriate for every situation.

Don't Use Temporary Email for Sensitive Accounts

A temporary inbox should not be treated like a secure personal mailbox.

Avoid using disposable addresses for:

Banking accounts
Important personal accounts
Password recovery for important services
Private documents
Sensitive business information
Accounts you need to keep permanently

For these situations, use a normal email account that you control.

What About Automated Testing?

For automated tests, temporary email can become more complicated.

A production-grade automated test suite may be better served by a dedicated testing mailbox, a local SMTP testing tool, or an email-testing API.

For example, a CI pipeline might use:

Application
    ↓
Create test account
    ↓
Send verification email
    ↓
Test email system
    ↓
Retrieve message
    ↓
Extract verification link
    ↓
Complete test

The important part is making the email system deterministic and reliable.

A public temporary inbox may be useful for manual testing, but it isn't necessarily the right infrastructure for every automated test environment.

Keep Your Tests Separate From Production

One of the best practices is to keep testing environments isolated.

If possible, use:

Test domains
Test databases
Dedicated email addresses
Separate API credentials
Separate user accounts
Staging environments

This reduces the chance of accidentally sending test emails to real users or modifying production data.

Final Thoughts

Email verification deserves the same attention as any other part of your application.

For manual testing, a temporary email address can help keep test registrations away from your personal inbox. For automated and production-like testing, dedicated email infrastructure may be more appropriate.

The right choice depends on what you're testing, how sensitive the account is, and whether the test needs a temporary or permanent mailbox.

The main goal is simple: keep test data separate, make email flows repeatable, and never use temporary email for information that needs long-term security or access.