The test builder

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

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, hover, press, tap, swipe
Navigation and waiting — goto, wait
Verification — assert, plus the toast / modal / validation-error presets
Capture — extract, api-request, wait-for-email
Network and time — mock-route, unmock-route, set-clock
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.

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.