A variable is a named value you define once and reference from many test cases as a {{NAME}} token. Instead of hardcoding a URL, an email, or a password in every case, you store it as a variable and let Robusty fill it in when the test runs. Change the value in one place and every case that references it picks up the new value on the next run.

Variables belong to a project and are shared by all of its test cases. They come in two forms:

Plain variables — the value is stored as-is and shown in the dashboard.
Secrets — the value is write-only. It's masked everywhere after you save it and redacted from logs and results. Use secrets for passwords, API keys, and anything else that shouldn't be readable.

Where you use variables

Reference a variable with a double-brace token: {{VARIABLE_NAME}}. Tokens resolve at launch time in two places on a test case:

The URL — for example {{PROJECT_URL}}/login.
The description — for example "Log in with {{TEST_USER_EMAIL}} and {{TEST_USER_PASSWORD}}."

While editing a test case, typing {{ opens an autocomplete list of the project's variables, so you don't have to remember exact names. Unknown tokens are left untouched: if a {{NAME}} has no matching variable, the agent sees the literal text {{NAME}}.

Default variables

Every project starts with two default variables. They always exist and cannot be deleted.

Variable	Value	Notes
`PROJECT_URL`	Seeded from the project's link when the project is created.	Editable and overridable. Build test-case URLs from it (`{{PROJECT_URL}}/checkout`) so one suite can target any environment.
`RANDOM_EMAIL`	A unique random email generated per test case at launch time.	Dynamic and read-only — you cannot edit, override, or delete it.

RANDOM_EMAIL is computed freshly for each test case in a launch, so two cases in the same suite never receive the same address. That keeps parallel signup and registration flows from colliding. The dashboard shows its value as "Generated dynamically per test run" rather than a stored value.

Managing variables

Open Variables in the project sidebar to see every variable with its name, value (or a masked placeholder for secrets), and when it was last updated.

Create — click New variable, enter a name and value, and optionally mark it a Secret. The secret flag can only be set at creation.
Edit — change a variable's value or name. For a secret, the value field is blank; leave it blank to keep the existing value, or type a new one to replace it. There is no way to reveal a saved secret.
Delete — remove a variable. Existing {{NAME}} tokens that referenced it are left as literal text in your test cases. Default variables (PROJECT_URL, RANDOM_EMAIL) can't be deleted.

Any project member (admin or editor) can manage variables.

Custom variable examples

Name	Secret	Example use
`TEST_USER_EMAIL`	No	The login email for a seeded test account.
`TEST_USER_PASSWORD`	Yes	That account's password, kept out of logs.
`PROMO_CODE`	No	A coupon the checkout test applies.

Reference them from a description like any other token:

Log in with {{TEST_USER_EMAIL}} and {{TEST_USER_PASSWORD}}. Open Billing,
apply the promo code {{PROMO_CODE}}, and confirm the discount appears in the
order total.

Overriding variables per launch

A variable's stored value is the default, but you can override it for a single launch without editing the project. Overrides apply only to that run; the stored value is unchanged.

The most common use is pointing {{PROJECT_URL}} at a preview or staging deployment so the same suite validates any environment.

From the dashboard: when you run a suite manually, the Launch test suite dialog lets you add overrides. Pick a variable, enter a value, and add it — only the variables you add are overridden, the rest use their stored values.

From the CLI: pass --var KEY=VALUE, repeating the flag for each override.

robusty launch --suite <id> --var PROJECT_URL=https://pr-34.preview.example.com

This is the recommended pattern for CI/CD: point one suite at different deployments.

Only stored variables can be overridden. RANDOM_EMAIL is generated per run and ignores any override.

Credentials

Robusty authenticates test flows in two ways, both built on variables:

Credentials as secrets. Store a test account's email and password as variables (mark the password a secret) and reference them in the description. The agent types them into the login form like a real user.
RANDOM_EMAIL for signup and registration flows that need a fresh, unique address each run.

Variables