Variables

The {{token}} syntax, where values come from and in what order, capturing values mid-run, and why an unresolved token fails the step outright.

A test that hardcodes https://staging.example.com and a password only works in one place, on one day. Variables are how a Vera test stays portable: write {{baseUrl}} and {{password}} in the step, and let the run resolve them.

Syntax

Anywhere a step takes text, {{name}} is substituted at run time:

goto    {{baseUrl}}/checkout
fill    [data-testid=email]     {{email}}
fill    [data-testid=password]  {{password}}
assert  text  [data-testid=greeting]  contains  {{firstName}}

Names are word characters only — {{base_url}} and {{baseUrl2}} are valid, {{base-url}} and {{user.email}} are not.

Substitution reaches every string field of a step, plus the values of an api-request step's headers map — so an auth header can carry a token captured earlier in the run:

api-request  GET  {{apiBase}}/me
             headers: Authorization: Bearer {{token}}

An unresolved token fails the step

If {{name}} has no value, Vera does not type the literal text {{name}} into the page. The step fails immediately with a message naming the variable that has no value configured.

That is a deliberate choice. Typing {{password}} into a password field would produce a login failure, or a validation error, or a timeout three steps later — and you would go looking for a bug in the app instead of a missing variable.

Where values come from

Resolved in order, later winning over earlier:

Project variables — the defaults, set on the project.
Environment variables — a named environment (staging, production) overrides the project's values for the same names, which is what makes one test run against several deployments.
The active role's credentials — {{email}} and {{password}} are merged from the auth role the run uses, so AI-generated and recorded login steps fill real credentials instead of inventing them. An explicit project variable of the same name wins over this.
Values captured during the run — anything an extract or api-request step put into a variable, available to every later step.

In a cross-project chain the precedence is: project < chain < accumulated, so a value captured in segment one overrides the chain's starting value for segment two.

Capturing values during a run

extract takes something off the page; api-request takes it from a JSON response. Both write into the variable map for later steps:

1  goto         /orders/new
2  click        [data-testid=submit]
3  extract      [data-testid=order-id]  →  orderId
4  api-request  GET  {{apiBase}}/orders/{{orderId}}   →  status  (json: $.status)
5  assert       variable  status  equals  confirmed

This is the pattern that lets a browser test verify something the UI never shows — step 5 asserts on what the backend actually recorded, not on what the page claimed.

Sensitive values

A variable marked sensitive is masked at rest: it appears as *** in step results and in a chain run's variable snapshot, while the real value is used in-memory for substitution. Run history is shareable without leaking a token.

Credentials configured on a project or an auth role are stored with the project and treated as sensitive throughout.

Scope

Project variables and environments are per-project. Values captured in a run live for that run only — nothing an extract captures persists into the next run, which keeps runs independent and re-runnable in any order.