Conditional steps — "Run only if…"

Some pages don't always look the same: a cookie banner that only sometimes appears, a form that only renders when a toggle is ON, an OTP screen that only shows on new devices. A plain recording captures one of those states — and fails in the other.

A condition fixes that: any step can carry a "Run only if…" guard. At replay time Trq checks the condition against the live page; if it holds, the step runs as recorded — if not, the step is skipped (⊘), not failed, and the run continues.

Author a condition

1. In the Events tab, select the step — or multi-select (Cmd/Shift-click) a group of steps that share the same condition.
2. Right-click → "Run only if… (N steps)".

3. Fill the condition dialog:

• Element — a selector for the element the condition inspects. It's prefilled with the right-clicked step's own target (the common "click X only if X is there" case needs no typing), or pick "…use the target of a recorded step" to reference any element another step touched — e.g. guard form-fill steps on the toggle an earlier step clicked.
• Check — is visible · is (not) checked · is enabled/disabled · text equals/contains · value equals. State checks read the real control state (checked, aria-checked), the same way assertions do.
• Negate — run the step only when the condition is not true. Perfect for "click the toggle only if it isn't already on".
• Wait up to — the condition window (default 2s, configurable in Settings). Deliberately short: if the element hasn't appeared by then, the answer is "not there" and the step skips. The window only exists to absorb render timing on late-mounting elements.

Applying to a multi-selection puts one condition on every selected step. Each step still carries its own guard in the .trq, so you can delete or reorder steps freely — there's no block structure to break. Fine-tune (or remove) a single step's condition later in its Edit drawer → Condition section.

What it looks like

Guarded steps wear an amber if chip. On a run where the condition is false, they report ⊘ with the reason inline — and the run still passes:

Consecutive steps with an identical condition evaluate it once and share the verdict — a six-step guarded form pays the 2-second window once, not six times. (The verdict resets whenever a step actually executes, since the page may have changed.)

Example — a toggle-dependent form

The settings page renders the email fields only when Email notifications is ON, and Save works in both states:

1.  navigate  app.example.com/settings
2.  click     aria/Email notifications      if NOT aria/Email notifications · checked
3.  input     aria/Notification email = …   if aria/Email notifications · checked
4.  input     aria/Reply-to address = …     if aria/Email notifications · checked
5.  click     text/Daily digest             if aria/Email notifications · checked
6.  click     text/Save
7.  assert    text contains "Settings saved"

Step 2's negated guard turns the toggle on only when it isn't already (replaying a recorded click on an already-ON toggle would turn it off). Steps 3–5 then re-evaluate against the fresh state and fill the form. One recording, both starting states.

Skip vs. fail — the exact contract

• Condition false → the step is skipped: ⊘ in the Events list, reason in the report, run continues.
• Condition true, step fails → the step fails normally (pause-at-failure, retries, everything as usual). A guard never swallows a real failure.
• Assertion steps can be guarded too — "assert the badge is green, but only if the panel rendered".

Guards can hide regressions

A guard that skips is silent by design — but if a feature breaks and its element never appears again, the guarded steps skip forever and the test stays green. Prefer guarding only genuinely optional UI, and keep at least one unguarded assertion on the critical outcome (like step 7 above).