Quick guides

Jump straight to common workflows:

Why test with real emails?

Most applications depend on email for core product behavior:

  • account creation and verification
  • password reset and recovery
  • security alerts and compliance notices
  • transactional updates and notifications

Mocking email alone often misses production failures. Real inbox testing gives you deterministic end-to-end coverage.

Core testing pattern

Use a fresh inbox per test run. Then:

  1. Trigger the workflow in your app.
  2. Wait for the email to arrive.
  3. Assert required fields and links.
  4. Continue the user journey using extracted tokens or URLs.

This keeps tests isolated and repeatable.

Creating inboxes

Create an empty inbox with a random email address.

The result includes an inbox id and address:

Sending emails

You can send test emails directly from MailSlurp when needed.

Receiving emails in tests

After your app sends an email, use APIs to retrieve it.

Example application trigger and wait flow:

Extracting content for assertions

Read the body and assert business-critical values.

Extract values with regex when needed:

Special character note

Some providers encode symbols in HTML entities. If regex checks fail unexpectedly, inspect encoded body content first.

Framework integrations

MailSlurp supports multiple languages and test stacks.

CypressJS

Configure command/request timeouts so wait methods can complete:

Add a custom command or use the official plugin:

Usage example:

Playwright

Use MailSlurp SDKs (Node, Java, CSharp, Python) in Playwright suites.

Selenium

See Csharp Selenium example or Java Selenium guide.

Jest

See Jest example project.

Production-ready checklist

  • Test all critical user journeys with real inboxes
  • Assert links/tokens and follow-through behavior
  • Add deliverability diagnostics before major releases
  • Fail CI on email regressions
  • Track ownership for sender/auth changes

For deliverability and pre-send validation, pair this guide with: