Email testing in DoesQA

Built-in test inboxes, per-Test-Case mail isolation, and Mail Test Steps for registration, password reset, and passwordless login journeys.

Many products send email during signup, login, checkout, or account changes. DoesQA includes test inboxes and Mail Test Steps so those journeys stay inside one Flow. You do not wire a separate mail service into your tests.

Two inbox types

Inbox	Value	Use it when
Test Case	$testEmail or $testEmailShort	The message belongs to one Test Case, such as registration or password reset
Account	$accountEmail or $accountEmailShort	Several Test Cases should share one mailbox

Prefer Test Case for signup and reset flows. Each Test Case gets its own address for that Run, so parallel Runs do not read each other's mail.

What you can do in a Flow

A typical email journey looks like this:

• Wait for email pauses until the message arrives.

• Open email opens the message so the body is the active page.

• Use normal Action, Check, and Validator Test Steps on the open message. Click links, assert copy, or run checks such as accessibility on the email content.

• Close inbox returns to the application window.

Open Mail in the left navigation to inspect the Account inbox or a Test Case inbox while you build a Flow, or after a Run to review what arrived.

Common journeys

Journey	Guide
Register and verify email	Test registration and email verification
Forgotten password	Test a forgotten-password flow
Passwordless or magic-link login	Test passwordless login
Hands-on Mail steps	Interacting with emails

Compared with coded frameworks

Teams using Playwright, Cypress, or Selenium often add a third-party mail API and custom code to receive messages, parse links, and keep parallel tests isolated. DoesQA ships inboxes, wait and open steps, and hosted runners as one product. See DoesQA compared.

Related

• Interacting with emails

• Mail Test Steps

• Built-in Values

• Test registration and email verification