The test builder

Assembling a test in the visual builder: the action palette, reordering steps, the selector field, running with live per-step progress, and stopping a run.

The builder is where a test is assembled and edited, whether it arrived from the recorder, the AI generator, an importer, or an empty page. Three panels: pick an action, order the steps, edit the selected one.

Adding steps

The action palette lists everything a step can do, grouped so you are not scanning twenty-five entries to find an assertion:

Interactions — click, fill, select, check, uncheck, hover, press, drag, upload-file, tap, swipe, launchApp
Navigation and waiting — goto, go-back, go-forward, reload, switch-tab, wait, waitForLoadingComplete
Verification — assert, the toast / modal / validation-error presets, assert-console, assert-request, a11yAudit
Capture — extract, api-request, wait-for-email, screenshot
Network, time and dialogs — mock-route, unmock-route, set-clock, handle-dialog
Flows — use-flow
Control flow — if, else, end-if, loop, end-loop

Clicking one appends a step. See the actions reference for what each does.

Ordering steps

Steps are a flat, ordered list, and you reorder them by dragging.

Control-flow steps are markers rather than containers (see Control flow), so the builder indents the steps between an if and its end-if, and between a loop and its end-loop. That indentation is the only visual signal of where a block begins and ends — when you drag a step across a marker you change whether it is conditional, so watch the indent shift as you drop.

Editing a step

Selecting a step opens its editor, and the fields shown are the fields that action actually takes — a press step asks for a key, an assert step asks for an assertion type and then for the fields that type needs. You are not given a twenty-field form with three relevant boxes.

The selector field

Any step that targets an element gets the selector input, which lets you choose how to match rather than only what: test id, ARIA role, label, placeholder, text, or raw CSS. Prefer test id and role; text is the most brittle of the six. See Selectors.

Selector values render in a monospace face throughout Vera — as do URLs, durations and IDs. If it is a value the machine reads, it is monospaced, so it never gets confused with prose.

Running from the builder

Run the test and the steps execute live, each one showing its status as it goes: pending, running, passed, failed. A failed step keeps its error, and a healed step shows what the selector was and what it became.

The test is saved before it runs, so what executed is what is stored — a run never reflects an unsaved edit you have since changed your mind about. Unsaved changes are flagged, so you always know whether what you are looking at is what would run.

Runs record a video, a screenshot on failure, and per-step results. A screenshot step additionally compares against its baseline — see Visual regression.

Stop or cancel a run

A Stop button sits on every surface that shows a run in flight, and it appears only while the run actually is one — a button that could only 404 is worse than no button. Those surfaces are the builder, the project's run list, the row on the tests list, the chain run page, and the suite and Actor Scenario run histories.

A stop is cooperative, not a kill. Pressing it records the request; the executor notices at its next step boundary, closes the browser, records the remaining steps skipped with a reason, and writes the run cancelled. So the honest cost of stopping is the step currently in flight — a run sitting in a 45-second wait stops when that wait ends, and there is nothing to tune. If a test does something you cannot afford to have happen once more after you press Stop, the step to look at is the one running when you pressed it.

Which answer you get says what happened:

Answer	Meaning
Stopped	The run never started (it was still queued) or was already cancelled. Nothing executed.
Stop requested	It is executing somewhere. Keep watching — the terminal row is written by whoever holds the browser.
Refused	The run already passed or failed. A verdict is evidence and is never rewritten.

Pressing Stop twice is safe; the second is a no-op success.

cancelled is a real ending, not a failure. The run is metered like any other — it burned real browser seconds — but it is excluded from flake scoring (a person pressing Stop says nothing about how stable the test is) and it sends no notifications: you just did this on purpose, so paging the team about it is noise. It does not count as the first green run either.

Stopping is never plan-gated. An entitlement decides whether you may start work, not whether you may stop it.

Two cases have their own shape:

A run executing on your own machine through the local agent cannot be reached by the cloud, so the stop rides the agent's next heartbeat. That guide states the bound.
Load runs and security scans stop by killing the external process, not at a step boundary — see Load testing & security scanning.

Data-driven runs

A test can be parameterized with a dataset: one test, N rows, run once per row. That is the shape Vera uses for edge cases — one parameterized test with twelve rows is maintainable in a way twelve near-identical hand-written tests are not.

A dataset run is N separate runs, so there is no single row to stop: its Stop is a group stop, addressed by the group id the run stream hands out, and it reports what it reached. Partial success is the normal answer — rows that already finished keep their verdicts, rows in flight stop at their next step, and rows that never started never start.