How to test an app built with Claude Code

Claude Code is an agentic coding tool: according to its documentation it reads your codebase, edits files, runs commands and integrates with your development tools. It is a strong way to build a web app quickly. This guide is for people who ship an app that Claude Code wrote and want to know, before real users arrive, whether the published version actually works. You will get a pre-launch test plan and three ways to plug an independent test into your Claude Code workflow.

What Claude Code does for testing

Claude Code can write tests for untested code, run them and fix failures; its documentation gives this as a typical use. That covers the inside of your project: unit tests, lint, type checks. What it cannot easily show you is the deployed result as a stranger sees it: the real address, the real browser, the real sign-in page, the real mobile screen. Both views matter, and they catch different problems.

What usually breaks in apps built with an AI agent

A feature works in development but fails after deployment (missing environment variable, wrong redirect address).
The sign-in flow works for you and fails for a new account.
A page looks fine on a laptop and is broken on a phone.
Buttons and forms exist but do nothing, or show no error message.
Images lack text alternatives and the keyboard cannot reach the controls.
Pages are heavy and slow on a weak connection.
Cookies and tracking appear with no notice.

Pre-launch test plan for a Claude Code app

Run your own tests and the build locally, and read the output yourself.
Deploy to the public address your users will use.
Open the home page in a private window, on a laptop and on a phone.
Click every link in the main menu and the footer.
Create a new account with a fresh email, not the one you used in development.
Sign out, sign in again, and try a wrong password.
Run the main journey end to end (the thing your app is for).
Submit each form with an empty, a very long and an unusual value.
Use the keyboard only: can you reach and activate everything?
Check images for text alternatives and text for sufficient contrast.
Reload a deep page directly and visit an address that does not exist.
Look for secrets, test data or debug messages visible in the page.
Read the cookie and privacy notices as a visitor would.
Run an independent read-only test with Avalyz on the public address.
Fix the blocking findings with Claude Code, redeploy, and test again.

Plug a test into Claude Code

Claude Code reads a CLAUDE.md file at the start of every session, which its documentation describes as the place for instructions and checklists. Avalyz publishes a block you can paste into it, so that Claude Code tests the app after every deployment and reads the report:

Title it "Avalyz acceptance test" and write: after every deployment, test the app with Avalyz (read-only by default) and read the report.
Step 1: run curl -sS --max-time 150 -X POST https://avalyz.com/api/v1/tests -H "Authorization: Bearer $AVALYZ_API_KEY" -H "Content-Type: application/json" -d '{"url":"YOUR_APP_URL","attendre":true}'.
Step 2: read the JSON that comes back: verdict (GO, GO SOUS CONDITIONS, NO-GO, INCONCLUSIF), pourquoi (why), constats (findings, severity S1 to S4, with a title) and rapport_url (a path to append to https://avalyz.com).
Step 3: if the verdict is not GO, fix the S1 and S2 findings, redeploy, then run it again. If etat is en_cours (still running), read https://avalyz.com/api/v1/tests/ID again with the same key.

Keep your API key in the AVALYZ_API_KEY environment variable and never write it into the repository.

MCP server. Claude Code supports the Model Context Protocol, an open standard for connecting AI tools to external data sources. Download the Avalyz server file once with curl -O https://avalyz.com/av/integrations/avalyz_mcp.py, then register it with claude mcp add avalyz -e AVALYZ_API_KEY=YOUR_API_KEY -- python3 /PATH/TO/avalyz_mcp.py. Claude's documentation shows the same pattern, claude mcp add with --env or -e for variables and -- before the server command. Run claude mcp list or /mcp in a session to check that it is connected. Claude can then run tests and read the reports itself.

GitHub Actions. Claude Code's documentation lists GitHub Actions for CI. Avalyz provides a workflow file for .github/workflows/avalyz.yml that runs after every successful deployment and fails the CI if the verdict is NO-GO; the exact file is on the integrations page. Store the key in a repository secret named AVALYZ_API_KEY.

What an independent test adds

The assistant that wrote your code knows your intentions, so it tends to check what it meant to build. A separate tool that sees only the published address behaves like a visitor: it does not read your code and does not share the assistant's blind spots. Avalyz proves what it saw; it does not vouch for the rest, and a clean report is not proof that the app has no defects. It is a second pair of eyes, not a substitute for your own judgement.

Test your Claude Code app with Avalyz

Avalyz tests a web application from the outside, in real browsers, and returns a verdict with evidence. Start free at /banc: paste your app's address, no sign-up, 3 tests a day. Or open https://avalyz.com/essai?url=YOUR_APP_URL with your own address in place of YOUR_APP_URL: it fills in the address and starts the test.

Read-only by default. By default, nothing is created or changed on your app. Only public addresses are accepted.
Optional test account. If your app has a login, give a test account: the sign-in form is then the sole form submitted, and the signed-in pages are explored read-only.
A GO / NO-GO verdict with evidence, findings ranked by severity, and a report you can paste back into Claude Code so the fix goes to the tool that built the app.
Plans, in US dollars with no commitment, are on /tarifs; there is also a 14-day trial of the Pro plan with no card.

FAQ

Can Claude Code test its own app?

It can write and run tests inside your project, and with the setup above it can also call an external test on the deployed address. The independent test is useful because it does not share the context of the session that wrote the code.

Do I need an API key?

Not for the free test or the link. The key is needed for the command, the MCP server and the CI workflow. You get one from the "API keys" page of your Avalyz account; the trial needs no card.

Will the test change my data?

By default no. It is read-only; the sole form submitted is the sign-in form, with the test account you give. A write mode exists only at your request and requires proof or an attestation that you may test the site.

What does the verdict mean?

GO means no blocking finding was seen; NO-GO means at least one was, with evidence. The API can also return GO SOUS CONDITIONS or INCONCLUSIF when the picture is not clear.

Does Avalyz replace unit tests?

No. Unit and component tests are only inventoried. Avalyz judges the running app from the outside.