How to Test an App Built With AI

An AI-generated app can look complete while important behavior remains untested. A working demonstration of one successful path does not establish that invalid input, access control, or persistence works.

Build tests from the product requirements. Then examine what the application actually does when the expected conditions change.

Start with a user workflow

For a fictional private task app, the primary workflow is signing in, creating a task, viewing it later, and removing it.

Define the intended behavior before generating tests. Does a task persist after reload? Can users share records? What happens when saving fails?

A browser-only prototype may intentionally keep data only in memory. A test should check that stated contract rather than assume every app has durable storage.

Cover more than the happy path

Use normal input, boundary input, and invalid input. For a title field, that might include a short title, whitespace, the maximum permitted length, and a value beyond it.

Check that the user receives clear feedback and that invalid data is not accepted by the server merely because the browser usually blocks it.

Client-side validation helps the interaction, but a protected backend needs its own validation and security checks. Test the server behavior where applicable.

Use two fictional users

If the app has private records, create separate demo users and separate records in an environment you control.

User A should access A's record. User A should not read, edit, or delete B's record. Signed-out requests should follow the defined policy.

Test the actual protected operation, not just whether the interface hides a control. Record-level access failures can remain behind a polished screen.

Check state changes and persistence

After creating a task, reload or revisit according to the app's expected behavior. Check that a saved change appears where it should and that a failed save does not pretend to have succeeded.

Try a duplicate click or repeated submission in a controlled test. The desired behavior depends on the operation, but unintended duplicate records should not go unnoticed.

For destructive actions, define confirmation and recovery expectations before testing them with disposable data.

Define an independent expected result

Do not ask the same model to inspect its code and declare that the code is correct. Give tests a requirement-based reference.

A compact test record should include the requirement, setup, action, expected result, actual result, and evidence. If the expectation is unclear, resolve the requirement before deciding whether the test passed.

A test that merely repeats the implementation's assumptions may miss the original misunderstanding.

Automate the checks that matter

Start with repeatable checks for important behavior and previously fixed bugs. Keep manual review for qualities that automation does not establish on its own.