Setting up

Environments

An environment is where a run happens: a base URL, plus values that differ between dev, staging and production. One case runs against all of them without being rewritten.

Variables

Configuration → Variables holds values every case can use. Write {{name}} in any field and the run fills it in.

• The name is the same everywhere, so a case can be written before anybody picks an environment.
• A value is either the same everywhere or set per environment.
• Mark one secret and it is encrypted at rest, decrypted only when a run needs it, and never shown again.

Generated values

Some values should be different every run. Write them with ${…}:

Write	You get
${email}	a fresh address at your project's domain
${int:1-100}	a number in a range
${digits:6}	a code
${name}, ${company}, ${phone}	plausible people and companies
${date:+7d}	a date, relative to today
${pick:red|green|blue}	one of those

Name one to reuse it: ${int:1-100 as amount}, then {{amount}} anywhere later in the same case. A name must not collide with a variable or a parameter — the editor says so, and the run refuses rather than guess.

The Syntax page in your project lists all of them with live examples, and typing ${ in any field offers them.

App adapters

An adapter is your app's vocabulary: the elements you point at often, named once and reused. Bind them with the element picker — click through your product and Cettara records a selector that it has checked against the live page.

Preference order is data-testid, then a label, then an accessible role and name, and only then CSS — so renaming a class does not break your tests.

Fixtures

Files your tests upload, and files your tests downloaded. Both live under Fixtures, and an upload step attaches one by name.

Backend requests

A request calls your API in the middle of a test — to seed data, or to check what the UI claims. A later step reads the answer with {{request_1.response.id}}.