How to test code written by Claude Code

We built an app called The Confidant and it took us far too long to release. Every time we got close, the same fear came back: what if something breaks? So we built more features instead of checking the ones we had. We have watched founders and clients do the same thing since, and AI makes it faster, not better. “I built it in two weeks” is easy to say. How much testing did it get?

What we learned: if you ask AI to build an application, it builds and builds and misses some parts. If you give it an inventory, it can switch to testing. Then you find out how much is broken that you never thought about.

1. Take an inventory before you test anything

Don't start by clicking around. Start with a list of every screen, form and journey that is actually in the code, and what each one should do. The AI can write this list for you, because it can read every route and screen, but give it a format: one check per journey, the steps, and the result a user should see. Without that list you only test what you remember building.

Our free test-checklist skill does exactly this in Claude Code, Cursor or Codex: it reads the code and writes the checklist, grouped by area, with a column for each platform the app runs on (see AI software testing).

2. Test the paths it never thought of

AI writes the happy path: the user who fills every field correctly, on a fast connection, and never presses Back. Real users don't go the way you expect. The checks that find the most bugs in AI-written apps are:

• Empty and wrong input in every form, and very long text.
• A brand-new account with no data in it. Every list and dashboard should say what to do next.
• Back, refresh and a second tab in the middle of a flow.
• Tapping Save or Pay twice.
• A slow connection, then no connection.
• The admin screens opened by a user who isn't an admin, by typing the URL.

3. Check what it says it did

An AI coding tool will tell you a feature is done when the code exists. That is not the same as the feature working on screen, on every platform. Take its summary of the change and check each item it claims, one by one, in the running app. On a project with web, Android and iOS, a fix that works in the browser may never have reached the phone.

4. Don't let the same session grade its own work

Tests an AI writes for code it just wrote tend to pass, because they test what it built rather than what you asked for. Write the expected result for each check from what the app is meant to do, before any tests are written. Then the AI can write and run the Playwright or Maestro tests, but the expected result decides pass or fail, not the AI's opinion.

5. Retest every fix, and what is next to it

AI fixes one thing and quietly changes another. A fix only counts when someone has repeated the original steps on the platform it was reported on, and used the screens around it. That is the difference between retesting and regression testing, and AI-built apps need both every time. Keep a short list of paths that must never break and run it after every change (see the regression testing checklist).

The checklist

Fourteen checks in three groups. Copy them, or import them and add your own app's journeys.

# Checks for an app an AI wrote

## Inventory: what was actually built (INV)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| INV-01 | Every screen in the code is reachable | The list of routes or screens from the code | 1. Open each screen from the app's own navigation, not by URL. | Every screen can be reached, and none is a dead end. | | | |
| INV-02 | Every button does something | Each screen open | 1. Tap every button, link and menu item. | Each one does what its label says. No silent taps, no placeholder pages. | | | |
| INV-03 | Every form saves | Each form in the app | 1. Fill it in. 2. Save. 3. Reload. | The saved values are still there after a reload. | | | |
| INV-04 | What the AI said it built is there | The AI's own summary of the change | 1. Check each item it claims, one by one. | Each claimed feature works on screen, not just in the code. | | | |

## The paths it did not think of (EDGE)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| EDGE-01 | Wrong or empty input | Any form | 1. Submit it empty. 2. Submit wrong formats and very long text. | A clear message beside the field. Nothing saved half-way. | | | |
| EDGE-02 | An empty account | A brand-new account with no data | 1. Open every list and dashboard. | Each one says what to do next instead of breaking or showing nothing. | | | |
| EDGE-03 | Going the wrong way round | Signed in | 1. Use Back mid-flow. 2. Refresh mid-flow. 3. Open the same flow in two tabs. | No duplicate records, no lost data, no stuck screens. | | | |
| EDGE-04 | Tapping twice | A Save or Pay button | 1. Tap it twice quickly. | It happens once. | | | |
| EDGE-05 | A slow or dropped network | Network throttled, then cut | 1. Repeat the main journey. | A loading state, then a clear error. It recovers when the network returns. | | | |
| EDGE-06 | The other role | Two accounts with different roles | 1. As the lesser role, open the admin screens and actions by URL. | Refused, on the server as well as in the menu. | | | |

## The fix and what is next to it (FIX)

| ID | Journey | Preconditions | Steps | Expected result | WEB | AND | IOS |
|---|---|---|---|---|---|---|---|
| FIX-01 | The reported bug is gone | The original issue's steps | 1. Repeat the steps exactly, on the platform it was reported on. | It no longer happens. | | | |
| FIX-02 | Every platform got the fix | A fix in shared code | 1. Repeat the steps on each platform. | Fixed everywhere, not only where it was reported. | | | |
| FIX-03 | Nothing next to it broke | The screens around the fix | 1. Use the rest of the changed screen and the screens that read the same data. | They behave as before the fix. | | | |
| FIX-04 | The paths that must never break | Signed out | 1. Sign up, sign in, reset a password, do the main journey. | All of them still work. | | | |

Or take the file: Markdown·CSV·Excel·no email, no sign-up.

Let the AI work the board, not just the code

In qarunbook the checklist becomes a board with a result per platform. Testers record what they see and raise issues against a check. Claude Code, Cursor or Codex connect over our QA MCP server, read what is failing, fix it, and send it back. The check goes back for a retest, never straight to passed, so “done” means someone saw it work. The Claude Code QA skill keeps the assistant to those rules.