Saving one
Press Save as procedure under a finished run in the chat, and give it a name. The procedure is built on the server from the run itself. What gets saved is what actually worked:- An Enter key the page ignored, recovered by clicking the field’s own submit button, saves as that click.
- A typed value a combobox committed as a selection saves as the selection.
- A click skipped because the page was already there saves as nothing at all.
- A step that used a
{{token}}saves with the token, so every replay generates a fresh value. - Coverage-gap placeholders are stripped.
Passwords in a procedure
A password the run typed is saved encrypted, so the replay can type the real value. Every view of the procedure, in the app and the API, shows***
instead.
The saved password is only typed on the project’s own address, one of the
project’s environments, or the preview of a pull request in the linked
GitHub repository. A replay aimed anywhere else, for example with a
--base-url on another host, is refused before the browser starts. To test
another host, add it as an environment.
A procedure saved from a Should fail run keeps that intent: it replays as
a negative test wherever it runs, whatever the chat’s chip says.
Running one
Every path runs against the project’s default environment
unless told otherwise. The app, schedules and the API can pick another
environment; the CLI and the API can override the base address instead.
More browsers, viewports and attempts
The More settings button on a procedure’s row holds its matrix options. They apply when the procedure is run from the app.
The options multiply: Chrome and Firefox, on desktop and mobile, three times
each, is twelve runs. Before a run like that starts, the app asks and names
the total.
Replays from a schedule, the API, the CLI or the PR bot run once, in Chromium,
at desktop size.
Login and auth mode
Every procedure has an auth mode that decides how its browser starts. Set it under More settings.
New procedures get a conservative guess from their name and steps; change it
if the guess is wrong.
Capturing a login state
Turn on Login setup for a sign-in procedure (under More settings). A procedure that does nothing but sign in is marked for you when you save it. When it passes, the browser’s session is captured right after the sign-in, encrypted and stored on the project. Every later run that reuses login state starts already signed in. A failed run never replaces a saved login. Only one procedure per project can be the login-setup procedure. The saved session itself is never shown or returned by the API; the project only says whether one exists and when it was captured. Re-run the login-setup procedure whenever the session expires.Exporting
Export as code on a procedure’s row, orGET /api/procedures/{id}/export, returns the procedure as a standalone
Playwright spec, useful for taking a flow into your own repository, or for
seeing exactly what a step does.
The export holds no secrets. A saved password becomes
process.env.TESTORIM_SECRET_<field>, a project variable becomes
process.env.TESTORIM_VAR_<name>, and a mid-run prompt becomes
process.env.TESTORIM_PROMPT_<field>. Built-in generators such as
{{random.email}} become code that generates a value once per test.
Maintenance
A procedure is only as good as the page it was recorded against. When a redesign moves things:- The flakiness dashboard on the project overview sorts your procedures worst-first, so the ones drifting show up before they fail outright.
- A failed replay is attributed:
testmeans the step no longer matches the page,appmeans the site is genuinely broken. - Steps cannot be edited in place. Re-record by describing the flow in the chat again and saving the new run.