Testing a site behind a login or a preview gate
Get through a login once, in one shared opening the other tests reuse, with the credentials held as secrets the tests reference by name and never contain. For a preview gate (basic auth, a Vercel or Netlify password, an allow-listed host), tell the tool which hosts it may visit and give it the gate's credential the same way. The rest of the suite then starts where a signed-in person would.
Why this is where suites get stuck
The first test anyone writes is "sign in", and the first thing they do is paste the password into it. Then the test is shared, the password is in the repository, the suite needs a second account, and every test repeats the same five steps. When the login page changes, fifty tests fail at step one.
The shape that works
One opening, used by many. Record the sign-in as its own test and mark it as something other tests use as their opening. A test that needs a signed-in session starts with "use: sign in". When the login page changes, one test is repaired and fifty follow.
Secrets by name. The sign-in test fills the password field with a reference to a variable named password, and the project holds the value as a secret. Secrets are entered once, never shown back in the workbench, blurred in screenshots and logs, and scrubbed from anything a model is shown. A test exported or shared carries the name, not the value.
A session the tool can reuse. After the opening succeeds, the browser's storage state is what matters. A tool that keeps it can start later tests from it instead of signing in each time, and can discard it to prove a test on a fresh session when that matters.
Two-factor codes and magic links
A test cannot read a phone. It can read an inbox, if you give it one: a test mailbox the tool can poll for the code, or a development endpoint that returns the last code sent. Where neither exists, an exploring agent will ask a person for the code and wait, with the answer kept for the run. On a desktop it can hand the browser over for the sign-in and take the recording back afterwards.
Preview gates
A preview environment is often behind its own door before the product's login. Three common cases:
- Basic auth. The username and password go in as secrets and the tool sends them with every request to that host.
- A password page from the hosting provider. Treat it as one more opening: a test that enters the gate password, used by the sign-in test.
- An allow-listed host. The tool has to know which hosts it may follow. Set the allowed hosts per environment, and let it ask when a flow leaves them, rather than failing silently on a redirect.
The environment's base URL changes with every preview deploy. Keep the URL out of the tests and pass it in when the pipeline triggers the run.
A worked example
A composed example: the team, the timings and the counts show the shape of the work and are not measurements from one customer.
A team's staging site sits behind a Vercel password and then its own email-and-password login.
They create two secrets, gate_password and password, and a test account.
Their first test, "pass the gate", enters the gate password.
Their second, "sign in", uses the first and signs the account in.
Every other test uses "sign in".
Their deploy pipeline triggers the suite with the preview URL for each pull request. When they move the login button into a menu, "sign in" fails, a repair is proposed and approved, and the other thirty-one tests never noticed. The passwords live in the project's secret store; the repository and the test exports hold only their names.
FlowQA explores your site, writes the tests, proves them against a broken page, and keeps proving them after every change.
See FlowQA