← siteglass blog

How to test an app your AI built (with no test code)

An AI agent can scaffold a working web app in an afternoon. It will not, however, tell you that the signup form silently fails when the email already exists, that the checkout button does nothing on mobile, or that a third of your pages throw a console error before they finish loading. The code looks done. Whether it works is a separate question — and it is the question almost nobody asks until a user does.

This is a short, practical guide to testing an app you (or your AI) built, when you have no test suite and no desire to write one.

Why AI-built apps break in their own particular ways

Generated code tends to ship the happy path beautifully and skip everything around it. The patterns repeat across thousands of apps we scan:

• Optimistic flows. Forms assume success. Submit an empty field, a duplicate email, a wrong password — and the UI either hangs, swallows the error, or pretends it worked.
• Dead controls. Buttons and links that were styled but never wired. They look clickable; they do nothing.
• Unhandled async. A failed fetch throws into the console, the spinner spins forever, and there is no fallback state.
• The login wall. The interesting part of the app sits behind auth, so it never gets exercised — not by you, and definitely not by a first-time visitor deciding whether to trust it.

None of these show up when you click through your own app the way you always do. They show up when someone does something you didn't expect.

Your three options

1. Click around manually. Free, and worth doing once. But you will test the path you built, not the paths that break, and you will not catch a console error or a slow paint by eye.

2. Write real tests. Playwright or Cypress are excellent. They are also a project: selectors to maintain, a CI pipeline to wire, flakes to chase. If you shipped the app to avoid that kind of work, you will not keep the tests current. Stale tests are worse than none.

3. Have something generate and run the tests for you. This is the gap siteglass fills, and it is what the rest of this guide walks through.

The no-code testing loop

The idea is simple: a tool renders your live site in a real browser, figures out what the pages and forms do, writes executable tests from that, runs them, and shows you exactly what happened. No install, no selectors, no pipeline.

1. Crawl. Point it at your URL. It renders every page (real browser, real JavaScript), and reports what is there: pages, forms and their fields, links, performance, and where the structure is coming apart.
2. Generate flows. The crawl becomes runnable end-to-end tests — load the home page, submit the signup form, search, check out — each automatically classified safe vs. destructive.
3. Run and watch. The flows execute with a screenshot at every step, a session video, and a full DOM replay you can scrub through. When a selector breaks mid-run, it is repaired against the live DOM instead of failing.
4. Read the findings. Broken links, JavaScript errors, slow paints, accessibility violations, and the flows that didn't pass — with the replay to show you why.

What to check first

If you do nothing else, exercise these four things, because they are where AI-built apps fail most:

• Signup and login, including the unhappy path. Empty fields, a duplicate account, a wrong password. Does the app tell the user what went wrong, or just stop?
• Every form's failure case. Submit with required fields blank. A form that only handles success is a form that will lose data.
• The console. Open dev tools, load each page, and look for red. A page that throws on load is a page that is broken for someone.
• The logged-out experience. What does a brand-new visitor — or an AI agent, or a link preview — actually see before they sign in? Often far less than you think.

An honest note on limits

Automated testing finds what is mechanically wrong: broken links, errors, dead controls, failed flows. It will not tell you whether your product is a good idea, whether the copy lands, or whether the design is any good. Those still need you. What it buys you is the certainty that the thing you shipped actually runs — for everyone, not just for you on the laptop you built it on.

That is a small guarantee. It is also the one your users assume you already made.