Email Flow Testing

Nobody tests magic links in CI. You should.

V1 does not intercept email for you. Use your own inbox tooling or test-login setup, then run approved Zerocheck checks against the browser-visible login, onboarding, and session behavior.

Who this is for

Role
Engineering lead or founding engineer
Company
PLG SaaS where magic links are the primary authentication method
Trigger
Magic link expiry bug locks out users, onboarding email stops sending after template change, or password reset flow breaks silently

The pain is real

“In the rush to get stuff out, time-consuming things get skipped like user testing, automation, analytics, monitoring, and manual testing… These bugs will keep annoying people using and relying on the software.”

The Pragmatic Engineersource

“Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is.”

Michael Feathers, Working Effectively with Legacy Codesource

“The same pattern kept repeating itself: a harmless-looking UI change, a merge, and then a failing test in CI.”

monday.com Engineeringsource

No CI tool handles email-based flow testing natively

Integrating email testing requires 3–4 separate tools that nobody has unified

Auth/session failure mode rated critical severity, large solution gap across research

Why nobody else solves this

E2E testing tools can drive a browser but can’t receive emails. Email testing tools (Mailtrap, Mailosaur) can receive emails but can’t drive a browser. Integrating them requires 2–4 hours of plumbing per project that nobody wants to do.

The result: magic link flows - the most critical user journey in PLG apps - are universally untested in CI. This is distinct from enterprise SSO/SAML, which requires IdP tenant management. Email flow testing has the same pain severity but dramatically lower adoption barriers.

The workflow today vs. with Zerocheck

Without Zerocheck

Developer changes magic link expiry from 24 hours to 1 hour for security reasons. Off-by-one error: link expires in 1 millisecond instead of 1 hour. Unit tests pass - they mock the email service. No E2E test for the email flow exists. Merged. Next morning: 200 users can’t log in. They click the magic link; it’s already expired. Support is overwhelmed. The bug lives in production for 3 hours.

With Zerocheck

Customer-authored login setup provides a safe authenticated session. Approved onboarding and account tests run in the browser, with screenshots and step traces when auth-adjacent behavior regresses.

How it works

1

Use customer-authored login setup and environment variables for authenticated flows

2

Test browser-visible onboarding and authenticated product flows

3

Browser-visible auth and onboarding behavior is verified

4

Session state and visible app behavior verified in the browser

FAQ

How does Zerocheck intercept emails in CI?

Zerocheck does not currently intercept email in V1. Use customer-authored login setup, environment variables, or your own test inbox tooling for magic-link and email-code flows.

Does this work with magic links, password resets, and onboarding emails?

Not as a built-in primitive in V1. Zerocheck can still test the browser-visible parts of onboarding and authenticated flows once you provide a safe login path.

Is email flow testing flaky?

Email-driven flows are flaky when inbox polling and browser automation are glued together. Treat those as customer-authored integrations until Zerocheck ships first-class email primitives.

Nobody tests magic links in CI. You should.

Magic links and onboarding flows fail quietly. Zerocheck can run approved browser checks after you provide a safe login path.

Get a demo