Write tests

Test signup and email verification end to end

Give a Testsy run its own mailbox, create a synthetic SaaS account, follow its confirmation email and check the verified account in the app.

A successful form submission does not prove that a customer can use a new account. Test the full journey: submit the form, receive the confirmation email, follow its link or enter its code, and see the verified account in the app.

Testsy can give a run its own email address and read the message your application sends. The mailbox is included on the free trial. It does not require access to your personal inbox.

Open an editable signup and email test. Replace the start address and product-specific checks before saving it. Use a publicly reachable staging environment with an authorized test signup flow.

Write an observable requirement#

Use a requirement like this, adjusted to your product:

Create a new synthetic account using this run's email address and a test password.
Submit the signup form and check that it asks the user to confirm their email.
Wait for this signup's confirmation email in the run mailbox.
Open its confirmation link, or enter its confirmation code, as the app requires.
Check that the app confirms verification and shows the new account's workspace.
Reload and check that the account remains usable.
Do not invite real users or enter payment details.

If your product requires an account name, workspace name or a first task, specify a synthetic value and the expected screen. For example: “Create the workspace Release Demo and check that its name appears in the workspace switcher.” Keep each check tied to something the tester can observe.

Do not use a production customer's address or paste a live confirmation token into the test requirement. The run's mailbox gives each run a separate address, which also helps avoid reusing an existing signup.

Enable the mailbox and review the plan#

In the test options, enable Give this test a mailbox. When the assistant recognizes that the plan needs email, it can switch the mailbox on; still confirm that the saved options include it.

Review the steps and checks before saving. The plan should identify what the email must prove and the visible result after verification. It should not treat “we sent an email” on the signup screen as evidence that delivery happened.

For API or MCP clients, enable email in options.services. See mailbox options and MCP planning.

Inspect both the message and the browser#

After the run, inspect Messages for the sender, subject, arrival, extracted link or code, and the service call that read it. Inspect the replay for the confirmation page and the verified account state.

Keep expected and observed behavior separate. A message that never arrives, an expired link, an incorrect code or an account that remains unverified must not be replaced with an assumed success.

Message bodies and confirmation links can contain sensitive information. Only workspace members can see the Messages tab; normal share links omit those messages. Review any material you copy outside your workspace.

Diagnose a result that cannot pass#

Observation	What to inspect
The form rejects the run's address	Your test environment's permitted email domains and validation rules.
The app says it sent a message, but none arrives	The app's mail delivery logs, recipient address and sender configuration. The on-screen notice alone does not prove delivery.
A message arrives but the link is unusable	The confirmation link's host, expiry and environment. A link to a developer-only address will not work from the hosted browser.
A challenge prevents signup	The access barrier and your authorized staging setup. A blocked run is not a verified signup.
The tester cannot establish the account state	The check and available evidence. An inconclusive result needs investigation or a clearer observable expectation.

The exact verdict depends on what the run completed and could prove. Preserve a legitimate assertion failure; separate application behavior from access barriers and tester or infrastructure limitations. See verdicts for the distinctions.

Reuse the test after a fix#

Deploy the fix and rerun the saved requirement with a fresh run mailbox. Compare the original result with the new one. Once the flow is reliable, add it to your release smoke suite.

The run's address stops receiving messages when the run ends. Keep signup cleanup in your staging maintenance process; this test does not automatically delete the new account unless that behavior is explicitly part of its reviewed plan.