Steps & the Step Builder
In an Advanced test case, steps are the ordered actions and checks the agent performs. The step builder composes them so they stay reliable as your app changes.
The step builder is how you compose an Advanced test case. You build an ordered list of steps in plain language, kept structured and reorderable without locking you into brittle selectors. A Simple test case skips all of this. It's a single freeform task.
Why plain-language steps
Traditional E2E tests pin every action to a selector (#login-btn,
.nav > a:nth-child(2)). When the markup shifts, the test breaks even though the
behavior didn't. Auretis steps describe intent ("click the Sign in
button") and the agent resolves that intent against the live page each run. The
result is tests that survive redesigns and only fail when behavior regresses.
The five kinds of step
The element registry
Locate steps populate an element registry, the running list of elements you've found, each with a short description and a reference. Act and Assert steps point at a registry entry instead of describing their target again, so:
- One element, located once, can be reused by any number of later steps.
- A step can only reference an element after it's been located. You can't point at something a later step will find.
- The registry sidebar shows each element and how many steps use it.
The registry stores your description of an element, not a frozen selector, and is re-resolved on every run. When the page changes, the agent re-finds the element from your description, so references survive redesigns.
Per-step controls
Task and Act steps carry the same knobs as a test case, scoped to that one step:
- Agent capabilities: scrolling (on by default), navigation (address bar, back/forward, reload), and tab management (off by default). Grant only what the step needs.
- Custom instructions: a hint that applies to just this step.
Composing reliable steps
A few habits keep test cases stable:
- Describe what the user sees, not the DOM. "Click the Sign in button" beats targeting a class that changes between releases.
- One action per step. Small steps make failures precise. You see exactly which step broke.
- Assert as you go. Drop assertions at meaningful checkpoints, not only at the end, so a failure pinpoints the moment behavior diverged.
- Let the agent wait. Reach for an explicit Wait only when the app has no visible signal that it's ready.
Steps run top to bottom and stop at the first failure. Order them the way a real user would move through the flow.