Without a test account
Every check sees what a signed-out visitor sees. If your address sends a stranger straight to a sign-in page, your first check says so, and its findings are about the pages the public can reach. The New run screen says the same thing before a run starts: a signed-out run reviews what a logged-out visitor sees, and pages behind your login are not opened.
Add a test account
-
Make an account for testing
Sign up to your own product as a brand new user, on a staging copy if you have one. Do not use your own login, and never use an account with billing or admin rights.
-
Save it in Settings → Sign-in
Fill in the Login page path (where a signed-in run begins, such as
/login), the Test account email and the Test account password, then press Save product. The Success selector is optional: something that only appears once you are signed in, such as#dashboard. -
Check that it signs in
Press Check setup in Settings → Product. Its Sign-in recipe line says it signed in as your test account, or what went wrong.
-
Scan your pages
In Settings → Pages, press Scan for pages (Scan again if you have scanned before). The scan now signs in and finds the pages behind your login.
The password is stored against your account on the console, never in your code.
Run it signed in
Once a test account is saved, new runs sign in by default. Signed in? on the New run screen shows which way a run will go: Signed in signs in as your test account first, so the pages behind your login get reviewed too, and New visitor keeps the run signed out.
For a User simulation, What are you testing? sets it up in one click. Your product, signed
in signs in, starts inside your product and roams every page marked as yours. Your public
site, as a stranger starts at the front door instead. Pages that turn a stranger away are
counted as yours automatically. If your app lets anyone load its pages and works out who you are in the
browser, mark your pages with auth in Settings → Pages.
Use an account you can throw away
A signed-in run drives a real browser as a real user of your product, and it clicks things. It stays away from anything that looks like a payment, and from what cannot be undone, such as deleting the account. It only submits forms with test data if you switch on Live product writes in Settings → Product. These safeguards cannot cover every screen, so give it an account whose data you would not miss.
Google, single sign-on and codes
The console signs in the way a person would: it types the email and password into your login page. If your product only lets people in through Google, single sign-on, a magic link or a code sent to a phone, it cannot sign in. There are two ways around this:
- Give the test account an email and password, if your product allows one alongside the others.
- Run nth Labs yourself. On your own machine the command line
can carry a session you signed in to yourself, in your own browser, with
node cli.cjs session import. You sign in on your own machine, and nth Labs never sees the password.
When it stops working
If a signed-in run behaves like a signed-out one, the sign-in failed, usually because the password changed, the login page moved or your product locked the account. Press Check setup in Settings → Product. It tries the sign-in and says what went wrong, often in your login page’s own words, so you can fix it in Settings → Sign-in.
A session imported on your own machine expires like any other. When it does, runs say so: sign in again in your browser, export a fresh one and import it again.