Testing Login Flows
This guide shows you how to test a login flow in DontBreak: fill credentials, click sign in, and assert that the right page loads — all without writing code. You'll also learn how to reuse the login across tests, test the full new-user journey end to end, handle sites behind basic auth, skip login entirely with cookies, and test 2FA/OTP flows.
Build a basic login test
A login test is four or five steps. Create a new test pointed at your login page (or at your homepage, with a Click step on the "Log in" link first), then add these steps:
Start on the login page
Set the test's starting URL to your login page so every run begins from the same state. If your app redirects logged-out users to the login screen automatically, the starting URL can be any protected page.
Fill the email
Add a Fill action, select the email field in the live preview, and choose a saved variable for your test account's email — create one like loginEmail if you haven't yet. Targeting is visual: DontBreak captures the area you select plus its DOM details, so it matches the same field on every run. A Type Text action with a literal email works too, but a variable is reusable across every test and editable in one place. See Variables.
This account already exists, so its email is just a regular address — no need for a receivable inbox here. Save the temp @dontbreakemail.com addresses for the full signup journey below, where the test actually has to receive the verification email.
Fill the password
Add another Fill action, select the password field, and choose your password variable (e.g. loginPassword). Variable values are encrypted at rest, so the password isn't baked into the step in plain text where anyone who can open the test could read it.
Click sign in
Add a Click action and select the sign-in button in the preview.
Assert you're logged in
Add an Element is Visible assertion targeting something that only exists after login — a user avatar, a dashboard heading, a logout link. Add a URL Check assertion too if your app redirects after login (for example to /dashboard). Two independent assertions catch more regressions than one.
Want to see a working version first? The in-app example tests include Sign Up & Login and Password Reset — open one and inspect its steps.
Use dedicated test credentials
Never put a real user's password in a test. Create a dedicated test account with minimal permissions, and remember that anyone on your team who can open the test can see its steps. See Teams and Roles.
Turn login into a reusable
Almost every test of a logged-in feature starts with the same login steps. Save those steps as a reusable, then insert it from the Reusables tab in the action picker in any other test. When your login form changes, edit the reusable once and every test using it is updated automatically. See Reusable Components.
Sites behind HTTP basic auth
If your staging site sits behind HTTP basic authentication (the browser-level username/password popup), don't try to click through it — configure it instead. In the test's Settings → Authentication, toggle Enable Basic Authentication and enter the username and password. You can also set basic auth defaults at the test suite level so every test in the suite inherits them.
Skip login with Set Cookie
When the thing you're actually testing is behind the login — a settings page, a checkout — logging in on every run adds steps that can fail for reasons unrelated to your feature. If your app uses a session or token cookie, add a Set Cookie action as the first step with the cookie name and value of an authenticated session. The test starts already logged in. Keep one dedicated test for the login flow itself, and let the rest skip it.
Test the full new-user journey
The steps above assume the account already exists — perfect for the everyday case, where you reuse one stable test account (filled from a variable, or skipped entirely with Set Cookie) across every logged-in test. But that path never exercises the new-user experience: signup, the verification email, and the very first login.
Add one dedicated test for that complete journey — sign up with a temp email, verify, then log in:
- On your signup page, add Fill Temp Email on the email field (it auto-creates the temp inbox) and a Fill with Random password on the password field.
- Submit, then handle verification with Click Email Link ("Verify email") or Fill Code from Email.
- Finish by logging in and asserting you land authenticated.
Because the temp-inbox value is cached for the run, the address you signed up with is the same one you log in with later in the same test. The Email Testing guide has the full worked example. Keep this as one journey test — don't make every login-dependent test sign up fresh, or runs get slow and your app fills with junk accounts.
Clean up the accounts you create
DontBreak deletes its temp inboxes automatically when a run finishes, but accounts created in your application are your system's data — DontBreak can't see or remove them. The cleanest fix is a self-contained test: end the journey by deleting the account it just made (navigate to settings → delete account), so it leaves no residue. Otherwise run signup tests against a disposable or staging environment, or use identifiable addresses so a periodic cleanup job can purge them.
Testing 2FA and OTP logins
One-time codes sent by email are fully testable with DontBreak's temp inboxes. Use Fill Temp Email during sign-up so the account is tied to a test inbox, then at the 2FA prompt add Fill Code from Email — it waits for the email, extracts the code (numeric, alphanumeric, or a custom regex), and types it into the field you target. For magic-link logins, use Click Email Link instead. The Verify a Code example test shows the full pattern, and Email Testing covers all the email actions.
Don't stop at the happy path
Add a second test that types a wrong password and asserts the error with Page Contains (for example, "Invalid credentials"). A login form that silently fails is a bug your happy-path test will never catch.
This is a separate test because it has a different starting state — a successful login leaves you on the dashboard, so the error case can't continue from the happy path. It's also cheap coverage: an error path exercises logic, not cross-platform rendering, so run it on a single platform (Chrome Desktop) and save the full browser × device matrix for your primary login journey. See Browsers & Devices for the matrix and Run Quotas for how that maps to usage.