End-to-end testing a signup flow means checking the whole path a new user takes, from the first form field to the first screen after login, including the verification email. Scripts handle the browser part well and struggle with the rest. Sai runs the flow the way a new user would, on a real computer with a real inbox, and reports what broke.
What end-to-end testing a signup flow covers
End-to-end testing of a signup flow runs the complete journey of a new user against a real deployment: entering details, passing validation, receiving and using the verification email, finishing onboarding and reaching the product. It checks that the pieces work together, not only that each one works alone.
Unit and API tests can pass while signup is broken for real users, because the failures live between systems: an email provider, a redirect after verification, a payment step, a cookie that a different browser handles differently.
Why signup tests are hard to keep green
- The inbox is part of the flow. Scripted tests need an email API, a disposable inbox and patterns to pull the link or code out of the message, all of which break when the email template changes.
- Selectors drift. A renamed button or a new onboarding step fails a scripted test even when signup still works.
- Flakiness erodes trust. Google reported in 2016 that almost 16% of its tests had some level of flakiness, and about 84% of the pass-to-fail transitions it observed involved a flaky test.
- Not everything is in the page. Password manager prompts, file pickers and browser differences sit outside what a page script controls.
What to test in a signup flow
A complete signup check covers these paths. Use the list with any tool:
- Happy path: a new user signs up, verifies the email and lands on the right first screen and plan.
- Validation: empty fields, invalid email, weak password; every message appears next to the right field.
- Duplicate account: the same email cannot create a second account, and the error says what to do next.
- Verification email: it arrives, the link or code works once, resend works, and old links stop working.
- Social sign-in: "Continue with Google" creates the same account state as email signup.
- Paid plans and trials: checkout with a test card, the receipt email and the plan shown in the app.
- Onboarding: every step saves, back and skip work, and a refresh does not lose progress.
- Second browser: the new user can sign in from another browser or device.
Ways to run end-to-end signup tests, compared
| Approach | Setup | Verification email | When the UI changes | Best for |
|---|---|---|---|---|
| Manual QA | None | Done by hand | No change needed | Occasional checks before a launch |
| Scripted tests (Playwright, Cypress) with an email API | Code, selectors, inbox API keys | Through the email API and regex | Update selectors | Fast regression runs in CI on every commit |
| AI testing platforms (e.g. Octomind, Momentic, QA Wolf) | Connect the app, review generated tests | Varies by product | Self-healing tests or a managed team | Teams that want a maintained web test suite |
| Sai | A plain-English prompt | Reads the real inbox in Gmail | Works from what is on screen | Full-journey checks before release and after agent-written changes |
Sai does not replace a scripted suite in CI. Keep Playwright or Cypress for fast checks on every commit, and use Sai for the full journey, the parts outside the page, and the paths nobody has written a test for yet.
How to test your signup flow with Sai
- Prepare test data. A staging or preview URL, a test inbox, test payment details and CAPTCHA test keys (see below).
- Describe the paths. List the paths to check in plain English. The full prompt is in the Start with a prompt tab above.
- Watch the first run. Sai works in a real browser on its computer, and you can follow every step live.
- Review the report. You get pass or fail for each path, screenshots, timings and reproduction steps. Sai asks before opening any GitHub issue.
- Run it again when it matters. Schedule a nightly run against staging, or trigger it before each release.
Sai ranks #1 on OSWorld, the public benchmark for agents that complete tasks on a real computer. Once Sai completes a task, its steps are kept as code that replays the same way, so the nightly run does not need the model to work it all out again.
From your coding agent: add the Sai MCP server to Claude Code, Codex or Cursor. After the agent changes signup code, ask it to have Sai run the signup check on your preview deployment and read the results before you merge. You can also call POST /v1/agents/message from CI. Read the quick start.
Test data that keeps signup tests safe
- A test inbox per run. Gmail delivers mail sent to a "+" variation of your address, such as qa+signup-1006@example.com, to the same inbox, so every run gets a fresh address without new accounts.
- Test cards, never real ones. Stripe's test card 4242 4242 4242 4242 with any future date and any CVC succeeds in test mode. Stripe's agreement prohibits testing in live mode with real payment details.
- CAPTCHA test keys. Google provides reCAPTCHA v2 test keys for which every verification passes; for v3, Google recommends a separate key for test environments. Use them on staging rather than asking any tool to solve CAPTCHAs.
- Staging only. Point tests at staging or preview deployments, and clean up the test accounts they create.
Related use cases: write release notes from merged PRs and reproduce a bug report step by step.
Last reviewed October 5, 2026.