​

Intent-driven UI scenarios

Intent-driven UI scenarios are tests built around what the user is trying to do, not around fragile implementation details. A step can say “click the Sign in button” or “fill the email field with the admin address,” and Qodex resolves that intent against the live page. This makes the scenario easier for humans to read and easier for Qodex to repair when labels, layout, or selectors change.

​

How authoring works

When you ask Qodex to create a UI scenario, it opens your app in Chromium and drives the flow in a real browser. The agent reads the page, chooses the right action, performs it, and records two things for each step:

• Intent: the plain-English meaning of the step.
• Cached action: the Playwright action and selector that worked on the live page.

The intent remains the human-readable contract. The cached action is what makes future replays fast.

​

Verification after saving

By default, Qodex runs a scenario once after saving it, fixes only the step that failed if anything did, and runs it again. That verification run is recorded as a test run you can open, like any other run. If you ask for drafts only, for example “save these as drafts, don’t run them,” Qodex saves them without running and tells you they are unverified.

​

Corrections while Qodex drives

You can send a message while Qodex is driving the browser, such as “the login button is in the top-right corner, not in the form.” Qodex reads it at its next action and carries on with the correction instead of starting over.

​

Partial drives are kept

If a drive runs out of time before the flow is complete, Qodex saves the steps it already drove and tells you what the saved scenario does not cover yet. You can then ask it to add the remaining steps instead of starting from scratch.

​

How replay works

On repeat runs, Qodex does not ask the LLM to inspect every step again. It runs the cached Playwright action directly in Chromium. If the cached selector no longer works, Qodex uses the original intent, the current page snapshot, and the previous error to find a new action. That recovery path is bounded to known browser actions such as click, fill, type, select, press, hover, check, and uncheck. See replay cache and self-healing for the full recovery flow.

​

Checks Qodex has not made yet

Sometimes you ask for a check that Qodex never reached in the browser while authoring, for example because an earlier step was blocked. Qodex keeps that check in the scenario as a step marked not yet checked instead of dropping it or guessing. On a run, a not-yet-checked step is skipped rather than failed, and the steps and group members after it still run. The scenario reports skip, never pass, and the run page says how many requested checks are not yet checked in the browser. To resolve one, check it once in the browser and save the step, use Fix in chat on the run and ask Qodex to record it, or remove the step from the scenario.

​

Landing checks

A check on where a step lands should name the path you expect, not a pattern that matches any URL ending in a slash. Qodex refuses to save a URL check whose pattern would pass on any trailing slash, because such a check can pass even when the app redirects to an error page. The save message names the path check to use instead.

​

Authenticated scenarios

Authenticated UI tests do not need to log in from scratch on every run. Qodex can execute configured login steps once, capture the resulting browser storage state, and reuse it for later runs, including runs that happen in parallel. A scenario bound to an auth profile finds it by name in the environment the run targets. If that environment has no profile with that name, the run errors and says the profile is missing, instead of running signed out. See Auth profiles. Logins that send a one-time code or magic link by email can run unattended. Qodex waits for the mail in the project inbox and uses the code or link from it. That means a scenario that touches several protected pages can run with the right cookies and local storage without paying the login cost every time. The same login flow can also help API scenarios by capturing bearer tokens from the browser session when your API tests need authenticated requests.

​

When to use it

• You want tests written from user goals instead of selector code.
• Your UI changes often enough that hard-coded selectors become noisy.
• The DOM depends on role, feature flag, plan, or user state.
• You want Qodex to create a first draft of a flow from a chat brief.
• You need multi-role scenarios where different users interact with the same product flow.

For related UI scenarios, put them in a test group or folder. UI-only groups can be run with video recording, which gives each scenario in the group a shareable replay artifact.

​

When a hand-written test may be better

• You need exact control over every selector and wait condition.
• You are testing in an air-gapped setup where the first authoring pass cannot use an LLM.
• You need pixel-level visual assertions today. Visual regression diffing is on the roadmap.

​

Related

​

On the roadmap