A rule checks one page. But most problems live in the journey through the interface: sign in, open the payment page, fill in a form. An action is exactly such a journey, recorded once and replayed as many times as you like. Without actions, tests could not get past the first page. Below is how to record an action and what its reliability rests on.
What an action is
A scenario of working with the interface: open an address, fill in a field, pick a value, click a button, wait for the move to another page. An action can be recorded with your own hands, or described in words and received from the agent. Both live as a plain file in the project folder.
Recording
- Start recording in the addon panel — a red mark appears on the icon.
- Work on the site as usual: sign in, go to the section you need, fill in the form.
- Stop recording — the steps appear as a list. Extra ones can be deleted, and any step’s value can be corrected.
- Give the action a clear name and save it.
Clicks and typing inside the panel itself never get into the recording: the product does not record work with its own window.
Secrets, environments and variables
If you type a password during recording, the file receives the name of a variable instead of the value — the action reads it as ctx.vars.name. This way the password never lands in the edit history that everyone with access to the project’s code can see. On saving, the product reminds you about this once more — in case you typed something sensitive into a regular field.
The values themselves live in the project separately from the files. Credentials (passwords, tokens, headers) are stored encrypted and shown once, at save time. They never get into sources, logs, requests to the model or exports — only into the run’s process, at the moment it needs them. They can be replaced or deleted, and the encryption key can be changed; a key change affects all projects at once.
Variables are sets of values. The first one counts as active; the rest are kept in reserve and substituted by hand during rotation — when an account’s password changes, for example. The action itself does not change: the variable’s name stays the same.
Environments are different stands of one product, each with its own base address. An environment can also define its own variable values: they override the project’s. And so that a crawl never touches the live site by accident, there is a list of production hosts — without explicit permission the product leaves them alone.
How an action finds elements
Recording a click, the product remembers how to find that element on the page. This decides whether the action survives the next layout edit. The order is: first the developer’s special markers, then stable identifiers and labels, and only as a last resort the path through the page structure. The last option is the most fragile: change the markup once and the step is lost. Such steps are marked, so you can see the weak spot in advance.
Replay
The run button executes the action on the current tab. After the replay a new screen appears with the “via action” mark, together with the check results on the page the action ended on. When a scenario leads to another site, the product first asks for confirmation: leaving the boundaries of the site under test is not always allowed. The page’s address comes from the run’s environment — ctx.vars.BASE_URL — so the same action works on the test stand and in production alike: the environment changes, not the scenario.
Actions in words
A scenario can be described in text: “sign in and open the payment section”. The agent writes the action itself — using the knowledge it has accumulated about how your interface is built. The finished action appears unapproved: you need to run it and see what came out. If it is right — approve it; if not — delete it or ask for a correction. Only approved actions take part in tests, so a draft can never break a working check.
Setup and cleanup
Part of the journey repeats in every test: sign in, accept the consents, bring the stand to the right state. So that you do not describe it anew every time, the project has two lists of actions — Setup and Cleanup. The first runs before any test’s steps, the second after them.
A test can declare its own lists: then they fully replace the project’s — nothing gets mixed in. An empty list is also an answer: it switches the phase off entirely. Cleanup runs even when a step failed with an error: putting the stand back in order matters most on exactly those runs.
Honest limitations
- Steps go one line at a time — no loops, no conditions, no repeating blocks. This is deliberate: a transition between pages destroys everything that ran before it, and only a simple sequence survives that moment reliably.
- On a transition between sites a fragment may repeat — when a step leads to another domain, part of the scenario sometimes executes twice. Inside one site this does not happen.
- The overall time budget is about one minute per action. Long scenarios are better split: the shorter the action, the clearer the error when something breaks.
- Credentials not found is an honest run error — when a value is missing or was replaced, the action will not execute and the run honestly fails. That is why an action is best replayed on the test stand first.
Next: how to assemble a test from actions and rules — in the Tests section.