AI frontend testing: a complete workflow, not just code generation

If you have ever asked an AI agent to write a test for you and ended up watching it run, fail and then tweak the test until it passed —even when the implementation was wrong— this article is for you.

AI already writes a meaningful share of the frontend code that goes through my hands. That has moved the bottleneck: the hard part is no longer producing code, it’s producing code with the confidence that what you ship today still works tomorrow. AI frontend testing has stopped being something that happens after the fact and has become part of the same loop where the code itself is written. And that changes far more than it looks.

When I started working with TWD (Test While Developing), the idea was exactly that: tests that run in the browser, against your real application, while you develop. What has shifted over the last few months is that the entire flow —from setup to visual documentation of the suite— now lives inside a series of skills for Claude Code. Six steps, one single philosophy.

The problem: AI writes tests, but not yours

When an agent writes a test without context, the result tends to look the same across every project. It works in the abstract and follows generic conventions, but it almost never fits your codebase.

It doesn’t know how your application is structured, what gets mocked versus what runs against the backend, how your auth works or which selectors the rest of the suite uses. What it produces looks correct, but it costs you another twenty minutes of tweaking before you can commit.

The philosophy behind TWD boils down to one sentence:

Test what you own, mock what you don’t

Applied to an AI workflow, that idea translates into a very specific requirement: the agent needs a map of your project. Structure, mocks, auth, third-party modules, assertion patterns. Without that, what it generates is generic, and generic tests don’t build confidence — they add noise.

That’s why the first step of the flow is giving the AI that context in a format it can re-read on every interaction, because it’s the difference between an agent that improvises and one that reproduces the rules your team already respects. Across projects where we have spent years working alongside frontend teams, we have seen the same pattern: the quality of the agent’s output jumps the moment it stops guessing the context and starts reading it from a fixed place.

How the complete AI frontend testing workflow works

The flow is designed to be used in order. Each step solves a different problem and leaves the next stage ready to go.

1. /twd:setup — Analyses your project, asks you a handful of questions about auth, mocks, and dependencies, and generates .claude/twd-patterns.md. That file is the contract between you and the agent: from there on, every test it writes has to respect it.
2. /twd — Writes the test, sends it to the browser through a WebSocket relay, reads the result in plain text and, if it fails, fixes it and runs it again. No screenshots, no DOM dumps. The write-run-fix loop consumes a fraction of the tokens any other AI testing tool needs.
3. /twd:ci-setup — Detects your project configuration and generates a GitHub Actions workflow using the official twd-cli action. Coverage, contract validation and Puppeteer come solved out of the box.
4. /twd:test-gaps — Cross-references your routes with your test files and classifies each one as tested, partially tested or untested. Routes with mutations, permissions or payment flows show up first, marked as HIGH risk.
5. /twd:test-quality — Scores each test file across four dimensions (journey coverage, interaction depth, assertion quality, edge cases) and returns actionable suggestions.
6. /twd:test-flow-gallery — Generates Mermaid diagrams and natural-language summaries from your tests, so product and QA can read the coverage without opening an editor.

Why the agent also runs the tests

Most AI test-generation tools do the easy part: they produce code. They hand you a file and run it many times against a jsdom, or fire it off through a tool like Playwright, where the feedback loop is measured in minutes. And when a test fails, the agent often ends up tweaking the test until it passes —instead of fixing the implementation— just to get the suite back to green.

With /twd that step isn’t delegated away. The agent sends each test to the browser through twd-relay, a WebSocket connection between Claude Code and the TWD sidebar running inside your app. The test runs against the real DOM, with the real mocks, against the real component tree. The result comes back as text: passed, failed, and on failure, what the console said.

That has two practical consequences. The first is that token consumption stays low —and this is what makes the loop viable— because the agent isn’t processing screenshots or massive DOM serialisations. The second is that when a test doesn’t pass on the first try, the agent can read the error, adjust the selector query or the mock shape, and retry immediately.

The loop has a limit: if after three attempts the test is still red, it gets marked as it.skip and a comment is left in the file. It doesn’t block the rest of the suite and, more importantly, it doesn’t hide the failure. That’s the opposite of what many agents do, tweaking the test until it passes at any cost; here, when a test doesn’t pass, what’s questioned is the implementation, and you decide whether to fix it, review the test, or leave it as a reminder for later. An agent that silences the tests it can’t fix is worse than one that doesn’t write them at all. That transparency is what makes you, after a few weeks, trust what the agent hands back.

From “we have tests” to “we have good tests”

A green suite doesn’t mean you’re covered. I learned that the day a bug reached production on a route with an acceptable coverage metric, and when I checked it, I found that the only test touching it just verified that the heading rendered.

/twd:test-gaps is built for exactly that moment. It walks through your routes, cross-references them with your tests, and separates what is genuinely covered from what only has a smoke test. A checkout route that gets visited but never submits a form shows up as partially tested, flagged HIGH risk. The output is a list prioritised by risk, not a percentage.

Once the weak spots are identified, /twd:test-quality scores existing tests across four weighted dimensions:

• Journey coverage (35 %) — does the test walk through a full flow, or does it stop at the first render?
• Assertion quality (25 %) — does it check the API payload and the resulting state, or only that a button is visible?
• Interaction depth (20 %) — is there real variety of interactions, or is everything a click?
• Error and edge cases (20 %) — what happens when the form is empty or the API responds with 500?

Each file gets a grade from A to D and two or three concrete suggestions. Those suggestions feed directly into the brief for /twd, which rewrites the test targeting the gaps that were detected. Diagnosis and repair live in the same flow, with no need to manually translate “the quality of the assertions is weak” into new code.

The flow wraps up with /twd:test-flow-gallery, which takes those tests and turns them into Mermaid diagrams and plain-language summaries, placed alongside each file. Product stops asking “are we testing checkout?” because they can open the flow and see it. QA spots gaps without reading a single line of code.

What comes next

The complete AI frontend testing workflow is available as an open plugin in the twd-ai repository on GitHub, and the general TWD documentation lives at twd.dev. At Orbitant, we have been refining this flow on real projects for months, and what we’re exploring now is how to connect it with the rest of the chain: from the initial generation of components to preview environments and the coverage reports product consumes every week.

If part of your frontend code is already being written by an agent, this is the logical next step. Not so the AI can write tests —any tool already does that— but so it writes them following your conventions, runs them in your real browser, and leaves a readable trail for the whole team.