Test Your App in the Browser with One Command

Type /test and Mythex clicks through your live preview like a user would, takes screenshots, and reports what broke in chat. How to use it and when.

Mythex Team · 2026-09-29 · 3 min read

Type /test in the project chat and Mythex tests your app the way a person would: it opens the live preview in a browser, visits pages, clicks buttons and fills in forms, then reports in chat what worked and what didn't. You can point it at a specific flow — "test signup and the pricing page" — or let it take the obvious path through the app.

What it does

App Testing exercises your live preview, not just your code. Mythex drives a browser against the running app, captures what it sees — including screenshots when they're useful — and writes a summary of the results in the chat.

That is a different kind of check from reading the source. Code can look right and still fail in use: a button wired to the wrong handler, a form that submits but never shows a confirmation, a page that only breaks after you've logged in. The only way to find those is to use the app, and App Testing does that for you.

Why it helps

When you build with an agent, the preview is how you judge progress. You click around, it seems fine, you move on. But clicking through every flow after every change gets tedious, and it's easy to check the page you just changed and miss the one it quietly broke.

App Testing turns "does it still work?" into one message. You describe the path that matters, the agent walks it, and you get a report you can act on. Because it runs in the same chat, the fix is one more message away.

How to run it

Make sure Preview is running and shows your app. App Testing works against the preview, so if the preview is blank or still starting, wait for it or fix that first.
Type /test in the project chat. You can also ask in plain language — "test the app in the browser" works too.
Say what to focus on, if you want to. For example: "test signup and the pricing page", or "create an account, add an item, check out".
Read the report. Mythex summarises what it tried and what went wrong, with screenshots where they help.
Fix what it found with /fix or a normal Build message.
Run /test again to confirm the fix worked and nothing else broke.

When to use it

After a large UI change. A new layout or navigation can break flows you didn't touch directly.
Before you publish, to catch obvious breakage before visitors do.
When the preview looks fine but a flow might not be. Multi-step paths — sign up, then log in, then do something — are the ones most worth checking.

Getting good results

The clearer the request, the more useful the report.

Describe a happy path. "Create an account, add an item, check out" gives the agent a clear sequence to follow and a clear outcome to check. "Test everything" leaves it to guess what matters.
Name the pages or features you changed. If you've just reworked the pricing page, say so.
Test in small loops. Change something, test it, fix it, test again. It's easier to see what broke when only one thing changed.
Pair it with checkpoints. If a change broke more than it fixed, you can revert to the last good turn instead of patching on top of it.

Limits

It tests the preview, not your published site. App Testing runs against the live preview in your private workspace. It won't check the version visitors see at your published URL. Publish separately when you're ready.
The preview has to be running. If it isn't up, there's nothing to test.
It follows the paths you point it at. A focused request gets a focused check; it isn't an exhaustive test suite.
It reports; you decide. App Testing tells you what's broken. Fixing it is a separate step, with /fix or a Build message.

If you want to go deeper on tracking down a problem once you've found it, our guide on how to debug an AI-built app walks through the process. For the preview itself, see a private workspace and live preview for every project.

The docs page has the details: App Testing.