Error handling
Four settings decide what happens when a step fails: timeout, retries, on error and soft assertion. The test’s cleanup steps run at the end whatever happened.
Set them per step (Step properties), or as test-wide defaults (Test settings). A step setting overrides the test default.
Timeout
Section titled “Timeout”The longest a step may take. For a step that acts on an element, this includes waiting for the element to appear. Default: 30 seconds (test default), selectable per step as 15, 30, 45 or 60 seconds. Longer values can be set in the test file.
A target’s first locator gets the whole timeout. Fallbacks are tried quickly afterwards (see Element targets). That is why a step whose element is missing takes about the full timeout before failing.
Retries
Section titled “Retries”Extra attempts after a failure: Retries 2 means up to 3 attempts. Each attempt starts again from the beginning of the step. Default: 0. A Lookup retry dismisses the dialog and starts over. Block steps (If, loops) and component calls are not retried as a whole; their inner steps are.
Use retries for genuinely timing-dependent steps, not to hide a broken locator.
On error
Section titled “On error”What happens when a step has failed (after all retries):
| On error | Step shows | Test continues? | Run result |
|---|---|---|---|
| Abort (default) | FAIL | No. Remaining steps are not run (cleanup still runs). | Failed |
| Continue | FAIL | Yes | Failed |
| Ignore | WARN | Yes | Not affected |
Use Ignore for best-effort steps, e.g. closing a pop-up that only sometimes appears. Use Continue when later steps are still meaningful after this one fails.
Soft assertions
Section titled “Soft assertions”Validation steps (Exists, Visible, Text, Value, Attribute, URL, Expression) can be marked Soft assertion:
- the failure is recorded (FAIL),
- the test continues,
- the run is marked Failed at the end.
This is the right tool for checking many fields on one screen: one run reports every wrong field, not just the first.
Cleanup
Section titled “Cleanup”A test’s cleanup list runs after the main steps, whether they passed, failed or
aborted. Use it to delete records the test created, so runs leave no orphaned data.
- Give every cleanup step On error: Continue, so one failed delete does not skip the rest.
- Make cleanup tolerant: accept
404on deletes (expectStatus: "204,404"). - A failing cleanup step is reported like any step but never turns into a run error by itself.
Cleanup steps are written in the test file. The editor does not create them yet, but shows and runs them.
Loops that never end
Section titled “Loops that never end”While requires maxIterations and accepts maxDurationMs; For each and Repeat are
bounded by their list or count; Poll API is bounded by maxAttempts and its timeout.
Reaching a ceiling fails the step with a clear message, instead of hanging the run.
How the run result is decided
Section titled “How the run result is decided”| Situation | Run |
|---|---|
| Every step passed or warned | Passed |
| Any step failed (Abort or Continue) | Failed |
| Any soft assertion failed | Failed |
| Only Ignore-d failures | Passed (with warnings) |
| Data-driven: see row aggregation |