Email Flow Testing

Magic links rarely get tested in CI

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 often requires 3–4 separate tools

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

Why this stays unsolved

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.

Magic link flows are often left out of CI because teams need both inbox tooling and browser automation. This is distinct from enterprise SSO/SAML, which requires IdP tenant management.

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.

Magic links rarely get tested in CI

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

Get a demo