How it works

unotest connects your editor’s AI agent to your real application through an MCP server, and turns what the agent does into a reviewable test.

The loop

1. You describe a flow in plain English to your agent.
2. The agent explores your live app through ~37 MCP tools — reading a semantic snapshot, clicking, filling, recording each action.
3. It writes a scenario to unotest/e2e/<feature>/<name>.js with stable selectors and step("intent", …) labels.
4. It runs the scenario on the scenario engine and, on failure, pauses to inspect; the agent patches and runs it again.
5. You review and commit the .js.

Semantic perception, not pixels

The agent doesn’t look at screenshots. It reads a semantic snapshot of the page (web) or the accessibility tree (iOS) — roles, names, labels, test IDs, rendered as a token-cheap text outline. This is cheaper, more reliable, and stable across visual redesigns.

The scenario engine

Scenarios are plain JavaScript, but they don’t run in Node: there is no require, no fetch, no process. Files, HTTP, the shell and the database go through typed DSL calls — readFile, apiCall, shell, dbQuery — so what a test touches is in its diff. The engine is not a sandbox: a scenario runs with the rights of the user who started it, as a Playwright test does. Review an AI-written test as you would any code before you run it.

Stable by construction

Selectors follow a strict priority — getByTestId → getByRole → getByLabel → getByText → locator(css) — and the linter flags brittle patterns. Tests survive refactors because they target meaning, not markup.

Local-first

The MCP server, the browser/Simulator, the runner and the viewer all run on your machine. Your app never leaves it. No cloud, no account.

The ecosystem

Package	Role
@unotest/web	CLI · MCP server · runner (web)
@unotest/mobile	CLI · MCP server · runner (iOS)
@unotest/viewer	local results browser
@unotest/dsl	scenario parser + validator
@unotest/protocol	shared types