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

Variables

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

Environment headers

Encrypted at rest. Sent by the browser to the environment’s own address, never substituted into a step, never shown to a model.

Passwords in a procedure

Encrypted at rest. Kept when you save a run that typed a password, so the replay can type it. Shown everywhere as ***.

Mid-run prompts

Typed into a masked field while the run waits. Not saved as configuration.

​
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.

​
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

Tokens (an API token, a preview-deployment bypass) go in environment headers. They are encrypted at rest with AES-256-GCM, sent only to the environment’s own address, never substituted into a step value, and removed from every run’s trace. Every read shows the header’s name with *** for its value. Passwords are best handled by a saved procedure. When a run types a password and you save it as a procedure, the password is stored encrypted on that procedure. It is decrypted only for a replay, and only when the replay runs on the project’s own address, one of its environments, or the linked repository’s pull request preview; any other host is refused. Exports write it as an environment variable, never the value. Project database connections and the Slack connection are encrypted the same way.

​
Credentials for signing in

Three options, best first:
  1. A login-setup procedure. Sign in once as a saved procedure; the browser session is captured and encrypted onto the project, and later runs start signed in. The password lives in one procedure instead of every test.
  2. Let Testorim ask. Leave the credentials out of the instruction and the chat shows a masked form.
  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. A value a check reads back off a password field is stored as *** too. 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.