Credentials & Sign-In

Give TestDrive an identity to run as — sign-in, bearer token, or API key — and let it learn the login once

Most of what's worth testing sits behind a login. A credential is one identity this workspace can run as, and a test names the credential it should use.

Use a dedicated test account. TestDrive will click the buttons a real user clicks, including the destructive ones a test asks for. Give it an account whose data you don't mind it exercising.

Credential Kinds

Kind

Use it when

What you provide

Sign-in

The app has a login form

Username and password. TestDrive learns the sign-in once and replays it

Bearer token

The app or API accepts a bearer token

A token, sent as Authorization: Bearer …, with no sign-in step

API key

The API expects a key

A key, sent as a header (X-API-Key by default) or a query parameter

Secrets are stored write-only. TestDrive will tell you which keys a credential holds; it will never hand the values back.

The first authenticated run figures out how this application is signed into — where the fields are, what the submit does, what "signed in" looks like. That's recorded once at the workspace level and replayed for every credential afterwards, so the second run doesn't rediscover the login page.

The Learned sign-in section of the Credentials tab shows either the date it was learned or "Not learned yet — the first authenticated run will work it out."

Action

Effect

Clear learned sign-in

Drops the learned flow and every cached session. The next run relearns it

Clear a credential's session

Drops just that identity's cached session, leaving the learned flow alone

Clear the learned sign-in after you change your login page; clear a single session when one account's state has gone stale.

Choosing a Credential for a Test

Each test picks one, including "No authentication — runs signed out" — which is the right answer for a marketing page, a public API, or a test that's specifically about what an anonymous visitor sees.

A test that drives the interface and a test that issues HTTP requests want different things from a credential: the first needs something it can sign in with, the second needs something it can send on a request.

Who Can Manage Credentials

Adding, editing, and clearing credentials requires update permission on the workspace. Credential names must be unique within a workspace, which keeps "which one did that run use?" answerable from the run report.