Skip to main content
Testorim has three places to put a value, and they are not interchangeable.

Variables

Plain project configuration. Substituted into steps as {{token}}. Not encrypted.

Environment headers and cookies

Encrypted at rest. Applied to the browser context, never substituted into a step, never shown to a model.

Mid-run prompts

Never stored at all. You type the value while the run waits.

​
Variables

Project settings → Variables. Each one has a name and a kind: a fixed value, or a generated one such as a random integer in a range. Use them in an instruction as {{name}}:
A variable resolves once per run and keeps that value for every step that uses it. The built-in generators, {{random.email}}, {{date.iso}} and the rest, need no configuration.
Variables are not a secret store. They are plain project configuration, readable by anyone who can read the project, and they are substituted into step values that end up in run records. Put a real secret in an environment cookie or header instead.

​
What belongs in a variable

Good: a coupon code, a test account number, a search term, a SKU, a non-sensitive feature-flag name. Bad: an API token, a session cookie, a production password.

​
Secrets

Real secrets go in environment headers and cookies. They are encrypted at rest with AES-256-GCM, applied directly to the browser context, and never substituted into a step value, so they cannot leak into a run record, a report, or a share link. Project database connections are stored the same way.

​
Credentials for signing in

Three options, best first:
  1. A login-setup test. Sign in once as a saved test; the browser session is captured and encrypted onto the project, and later runs start signed in. The password lives in one test instead of every test.
  2. A session cookie in an environment. Encrypted, and skips the login UI entirely.
  3. In the instruction, for a throwaway test account only. The value is redacted before it is stored, but it was still typed into a chat box.

​
Redaction

Anything typed into a field whose name suggests a secret (password, secret, token, PIN, OTP, CVV, SSN) is stripped before the run is persisted, before the report model sees it, and before a shared link renders. That covers the typed value, the verification read-back, both sides of an assertion, and any error or warning that quoted it. Identifier-shaped names redact too: userPassword and secretKey, not just a bare Password. Link targets are masked where they appear in diagnostics, so an invite or password-reset token inside an href cannot ride out in an error message.