Your AI Doesn't Just Write Tests. It Runs Them Too.

Source: Dev.to

Writing Tests That Run in Your Real Browser

Most AI‑generated tests run in Node.js — against jsdom, a simulated DOM. That works for many cases, but it isn’t the same as running inside your actual application with real components, real routing, and real network mocks.

TWD tests run in the browser. They execute inside your running app, against the real DOM, with your actual component tree mounted. The /twd skill — part of the TWD AI plugin — writes the tests, runs them in your browser, reads the results, and if something fails, it fixes the code and runs again.

Full Cycle

1. Write – the agent reads your .claude/twd-patterns.md to understand your project’s test conventions, then generates a test that follows those patterns.
2. Execute – the test is sent to your browser via twd-relay, a WebSocket relay that connects the agent to the TWD sidebar running in your app.
3. Read results – pass/fail status comes back as plain text with error details (no screenshots, no DOM dumps — just the signal you need).
4. Fix and re‑run – if a test fails, the agent reads the error, adjusts the test, and re‑executes.

This loop runs automatically; you’re not involved until it’s done.

How the Relay Works (Without Getting Heavy)

twd-relay uses a WebSocket connection between the agent and the browser. When the agent wants to run tests, it sends a command through the relay. The browser executes the tests inside the running app — against the real DOM, with your mocked API responses in place, and the real component state.

Results come back as concise text: did it pass? and, if not, what was the error message. This keeps token usage remarkably low, giving the agent the same output you’d see in a terminal — structured and actionable.

Running It Before You Build

The recommended workflow is test‑first. Run /twd before you implement a feature.

/twd Write a test for the checkout form — it should verify that submitting with an empty email shows a validation error

The agent writes the test based on your existing patterns, runs it in the browser, and it fails — because the feature doesn’t exist yet. That failure serves as a specification. You then implement the feature, the test passes, and you didn’t have to think about test structure, selectors, or mock setup; the agent handled that using the patterns it already knows from your project.

What Happens When a Test Won’t Pass

Not every test is fixable on the first attempt. Sometimes the agent encounters a case it can’t resolve — a component that behaves differently than expected, or a pattern that doesn’t translate cleanly.

The /twd skill handles this with a hard limit: if a test still fails after three fix attempts, it is marked as it.skip and left in the file with a comment. It doesn’t block the rest of the test run, allowing you to investigate the real issue later. This approach maintains trust: failures are surfaced rather than silently hidden.

Keeping Your Conversation Clean

The /twd skill runs in a forked context, meaning the test iterations, failed attempts, and fix cycles happen separately from your main conversation. When it finishes, you receive a summary of what passed, what was skipped, and what files were created, without having to scroll through dozens of debugging messages.

A Concrete Example

Suppose you’re building a Vue component that fetches and displays user data. You invoke:

/twd Write tests for the UserProfile component

Behind the scenes:

• The agent reads .claude/twd-patterns.md to learn your project conventions, how to mock API endpoints with twd.mockRequest(), and which selectors to use with screenDom.
• It generates tests that mock the /api/users/:id endpoint, visit the page, and assert the displayed data.
• It runs them in your browser via the relay.
• If a test fails (e.g., a selector doesn’t match the markup), the agent reads the error, corrects the query, and re‑runs.
• All tests eventually pass.

Total time: less than two minutes, with no manual intervention.

What You Actually Need to Get Started

• The TWD sidebar running in your app (from twd-js).
• twd-relay running locally.
• .claude/twd-patterns.md generated by /twd:setup.
• The /twd skill installed from the twd‑ai repository.

That’s it. The relay handles the browser connection, the patterns file defines the conventions, and the skill orchestrates the rest.

Coming Next: CI Setup

Writing and running tests locally is only half the equation. The other half is integrating them into your CI pipeline so tests run headlessly on every push, without a browser in sight.

The next article in this series covers /twd:ci-setup, which configures your project to run TWD tests in CI using the headless CLI runner. If you’ve ever wanted your AI‑written tests to gate a deployment, that’s the one to read.