There is a category of test that feels productive, passes consistently, and catches absolutely nothing. It lives in most codebases. It gets written during sprints, committed without question, and reviewed without comment. Nobody talks about it because it looks fine.
It is the mocked email test.
What it looks like
jest.mock('../lib/email', () => ({
sendVerificationEmail: jest.fn().mockResolvedValue({ id: 'mock-id' })
}));
test('sends verification email on signup', async () => {
await signupUser({ email: 'test@example.com' });
expect(sendVerificationEmail).toHaveBeenCalledWith('test@example.com');
});
This test passes. It will always pass. It will pass when your SMTP credentials expire. It will pass when your email template has a broken link. It will pass when your transactional email provider changes their API. It will pass when the verification token generation has a bug that makes every link invalid.
You have not tested that the email works. You have tested that your code calls a function.
The lie
Mocking email is a form of wishful testing. You mock the thing you don't want to deal with — the network, the third-party service, the timing — and you replace it with a version that always does exactly what you tell it to do.
The mock never fails. The mock never bounces. The mock never ends up in spam. The mock never has a broken template. The mock is not your email system. The mock is a ghost.
When a real user signs up and the verification email lands in spam because your SPF record is misconfigured — your mocked test was passing the entire time. When your password reset link expires in 10 minutes instead of 24 hours because someone changed a constant — your mocked test was passing. When your email provider silently rate-limits your account and stops delivering — your mocked test was passing.
The test suite is green. The product is broken.
Why developers do it anyway
Because testing email is genuinely hard. The alternatives have historically been painful:
MailHog — run a fake SMTP server locally. Works until it doesn't, requires Docker in CI, abandoned since 2020.
Shared test inbox — use a real Gmail account for tests. Race conditions in parallel runs, manual cleanup required, leaks real credentials into CI.
Hardcoded bypass codes — add if (process.env.NODE_ENV === 'test') skip email. You've just made your test environment behave differently from production. Congratulations.
Skip it entirely — "we'll test email manually in staging." Manual testing doesn't run on every commit.
Every option requires either accepting the lie (mocking) or accepting the pain (infrastructure). So developers accept the lie.
What testing email actually requires
A real email test needs three things:
- A real inbox — not a mock, an actual email address that can receive mail
- Isolation — each test run gets its own inbox so parallel tests don't collide
- Automation — the test can read the inbox programmatically without human intervention
When you have all three, your test looks like this:
test('user can sign up and verify email', async ({ page }) => {
const inbox = mail.generateInbox();
await page.goto('/signup');
await page.fill('[data-testid="email"]', inbox);
await page.click('[data-testid="submit"]');
// Real email, caught at the edge, OTP auto-extracted
const email = await mail.waitForLatest(inbox, { timeout: 30000 });
expect(email.subject).toContain('Verify your email');
expect(email.magicLink).not.toBeNull();
await page.goto(email.magicLink!);
await expect(page).toHaveURL('/dashboard');
});
This test fails when:
- Your email provider is down
- Your SMTP credentials are invalid
- Your email template doesn't render the verification link
- Your token generation has a bug
- Your email ends up in spam filtering
These are exactly the things you need to know about.
The argument for mocking
There is a real argument for mocking: unit tests should be fast, isolated, and deterministic. Email delivery is slow, external, and non-deterministic. Unit tests that hit real email infrastructure are slow and flaky.
This argument is correct. And it is a reason to mock email in unit tests.
It is not a reason to mock email in integration tests or E2E tests.
The question is not "should we ever mock email?" The question is "what are we actually trying to verify?"
If you're testing that your signup controller calls the email service — mock it. That's a unit test.
If you're testing that a user can sign up, receive a verification email, click the link, and land on the dashboard — that is an E2E test. Mock nothing. Use a real inbox.
The cost of the lie
Every mocked email test is a gap in your coverage. Not a small gap — a gap in the exact flow that new users experience first. Signup, verification, password reset — these are the first things a user does. They are also the first things that break.
The production incidents that come from untested email flows are not subtle. They are "users can't sign up" incidents. They are "nobody told us the verification emails were going to spam for three days" incidents.
A mocked test suite would have passed through all of them.
The alternative is not that hard anymore
Disposable email APIs have made real inbox testing in CI straightforward. No Docker. No shared credentials. No cleanup.
npm install zerodrop-client
import { ZeroDrop } from 'zerodrop-client';
const mail = new ZeroDrop();
const inbox = mail.generateInbox(); // instant, no network request
The inbox exists. It can receive real email. It expires in 30 minutes. It works in parallel CI runs. OTPs are extracted automatically — no regex.
There is no longer a good reason to mock email in E2E tests. The pain that made mocking reasonable is gone.
Stop testing that you call the function. Start testing that the email arrives.
ZeroDrop — disposable email inboxes for CI pipelines. Free, no signup, no Docker.
→ zerodrop.dev · docs · npm
