Start with promises, not a test-count target
Test AI-generated code against what the product promises its users. Begin with the journeys where a failure loses money, exposes information or destroys work. Write the expected outcome before asking an assistant to generate tests. A large test suite can still check the wrong behaviour if the implementation and its tests share the same mistaken assumption. The practical aim is to make a release decision with evidence, not to reach an impressive number of green checks.
Separate customer feedback from engineering verification
April and June discussions ask where to find testers; August conversations emphasise the effort involved in operating a finished application. These are related but distinct problems. Potential customers can tell you whether the workflow solves their problem. A technical test plan examines whether the workflow behaves correctly under failure and misuse. A friend completing signup is useful feedback, but it does not establish that another customer’s records are protected.
Build a small risk table
Choose five journeys: sign up, recover an account, create or edit the main business record, pay, and leave or cancel. For each, write the normal result, a failure case, an unauthorised case and the evidence to retain. Assign an owner. For an appointment product, the main promise might be that one available slot produces one confirmed reservation. Test simultaneous attempts against that promise rather than only checking that a confirmation message appears.
Use browser tests for visible behaviour
Automate the important actions a customer takes: fill in the form, submit it and verify the resulting state. Prefer stable, user-facing locators and isolated test data. Playwright’s best-practice guidance recommends testing observable behaviour and keeping tests independent. Pair those checks with narrower tests for business rules. A browser journey is valuable, but it should not have to explain every calculation or access decision in the system.
Test permissions outside the happy path
Use two test accounts belonging to different organisations. Confirm that the second account cannot retrieve or modify the first account’s private resource through the API, even when it knows the identifier. Include a logged-out request and a user whose membership was revoked. Retain the allowed case too: an endpoint that denies everybody is unavailable, not successfully implemented. The accompanying Supabase guide develops this exercise for database-backed applications.
Exercise payment transitions and retries
An April billing discussion drew a useful objection: edge-case failures predate AI coding. Model subscription changes explicitly—trial, active, past due and cancelled—and write down the access your product intends for each. For Stripe integrations, verify webhook signatures, handle duplicate delivery and avoid relying on delivery order. Its documentation explains these behaviours. Test what happens when the browser closes after payment, the handler retries, or a delayed event arrives after a newer state. Use provider test environments and synthetic customers.
Make a regression test demonstrate its value
When correcting a defect, retain a minimal reproduction that fails against the broken behaviour and passes after the correction. Inspect the assertion: does it check the actual customer outcome, or simply echo a mocked success response? Ask an independent reviewer to challenge important expected results. A different AI model can suggest cases, but agreement between models is not proof. Include adjacent actions that could regress, such as an authorised update after tightening access.
Choose a release decision you can explain
Before launch, record the tested revision, environment, passing critical journeys and unresolved risks. Give each accepted risk a reason, an owner and a revisit date. Treat unverified access isolation or unreliable payment state as a reason to narrow the release until the issue is understood. A small pilot can reduce exposure, but it does not repair a broken boundary. After release, connect reported defects to the same test plan so that learning survives the next feature request.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Prepared with AI-assisted research and checked against the linked documentation. Community discussions inform the questions; they are not verified incident reports.