​

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.

​

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.

​

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. 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