Automation
Writing a test case
Every kind of step, and when to use it.
A case is an ordered list of steps. Build them by pointing at your app with the element picker, or by choosing an element the adapter already names.
The steps
| Step | What it does |
|---|---|
| Go to | Opens a path on the environment's URL. |
| Click | Clicks an element. Can be told to expect a download. |
| Fill | Types into a field. Values can be variables or generated. |
| Select | Chooses an option in a dropdown. |
| Attach | Uploads one or more fixtures. |
| Wait | Waits for an element to appear, disappear, be removed, increase in number, or for the network to go quiet — or simply pauses. |
| Backend request | Calls your API and keeps the response for later steps. |
| Checkpoint | Stops and asks the AI judge whether your expectation holds. |
| Do | Carries out an instruction in plain language. |
| If | Branches on a value, or on a question about the screen. |
| Stop | Ends the case early, on purpose. |
| Block | Runs a reusable set of steps. |
Waiting well
A wait gives up after your project's timeout. More options on the step overrides it for that step alone, and shows the project's value as the placeholder so you know what you are changing. For "the network goes quiet", you can also set how long quiet means.
Prefer waiting for something observable — an element, a count, the network — over a fixed pause.
Branching
An If step can ask about a value you have, or ask the model a yes/no question about the screen ("is the cookie banner showing?"). A visual question costs 1 AI credit; a value comparison is free.
Keeping cases readable
- Put the sign-in in a block, marked run-once.
- Name elements in the adapter rather than repeating selectors.
- Use a checkpoint where a person would look, not after every click.