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.

Give each credential the roles it signs in as. Name a role for what that user can do, like Workspace Admin or Reviewer: OttoTester reads these names to decide which credential a test signs in with. When one account can act as several roles — an admin in one workspace and a member in another — list them all on one credential, separated by commas or semicolons. They share one sign-in, so the password lives in one place. Each role name can be on only one credential in a variant.

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.
  • Wrong password. If the app turns a saved login down while OttoTester explores it to plan tests, the run stops right away instead of trying again. The run page names the role and quotes what the app said. Fix that role on the Credentials tab of Test Data, then run again.
Section titled “Related”