Skip to content
OttoTester docs

Set up authentication

Why a fixture

Section titled “Why a fixture”

Most of what you test sits behind a login. You could make every test sign in first — but that’s slow, and it repeats the same flow everywhere.

Instead, OttoTester uses a fixture: a small test whose only job is to sign in. It runs once, before your real tests, and saves the session to a file (.auth/<role>.json). Every test after it starts already authenticated. See Fixtures and test data for the concept.

1. Provide credentials

Section titled “1. Provide credentials”

OttoTester needs a username and password — and a TOTP secret, if the app uses two-factor — to sign in with. Add these as credentials on the variant. They’re stored encrypted, and the fixture reads them at run time; they’re never written into a script.

2. Let the planner build the fixture

Section titled “2. Let the planner build the fixture”

When the planner explores an app and hits a login wall, it writes a fixture plan — the spec for the sign-in flow — and the generator turns that into the runnable fixture. For many common identity providers (Login.gov, Okta, and others) OttoTester has ready-made fixture templates it can use instead of composing one from scratch.

You don’t usually hand-write a fixture. You provide the credentials; the agents work out the login flow.

3. Check it worked

Section titled “3. Check it worked”

After a run, confirm the fixture produced a .auth/<role>.json file and that the tests for that role ran signed in. If a test that should be authenticated is bouncing back to a login page, the fixture is the first place to look.

What the Okta sign-in helper covers

Section titled “What the Okta sign-in helper covers”

If your app signs in through Okta, OttoTester has a ready-made helper, so you usually only provide the credentials and it takes care of the rest.

It handles, out of the box:

  • The standard Okta sign-in box, in both of its layouts — the one that shows the username and password together, and the newer one that asks for the username first and the password on the next screen.
  • Sign-ins that use a username and password, with or without a code from an authenticator app.
  • Standard Okta web addresses — the ones ending in okta.com, oktapreview.com, or okta-emea.com.

It can’t automate these — but it won’t fail silently. When it sees one, OttoTester learns your sign-in by watching it once instead:

  • “Approve on your phone” prompts, codes sent by text or email, security questions, and hardware security keys. These need a real person, so they can’t be automated.
  • A heavily customized sign-in box that doesn’t look like the standard Okta one.
  • A sign-in address on your own domain (for example login.yourcompany.com). OttoTester won’t recognize it as Okta automatically, so — like the cases above — it learns your sign-in by watching it once instead.

Multiple roles, multiple environments

Section titled “Multiple roles, multiple environments”
  • Multiple roles — if you test as admin, tester, and reviewer, you’ll have one fixture per role. Each test declares which role it needs.
  • Multiple environments — staging and prod are separate variants, usually with different credentials, so each variant has its own fixtures.

Common snags

Section titled “Common snags”
  • Expired sessions — a saved session can age out. OttoTester re-runs the fixture each run, so this is rare; a very short server-side session lifetime can still cause it.
  • Two-factor — supported through a TOTP secret stored with the credentials. A push-to-approve second factor that needs a human can’t be automated.
  • CAPTCHA — a login gated by CAPTCHA is built to block automation. There’s no way around it.
Section titled “Related”