Coding with AI
A test plan for AI-assisted code changes
Build tests from the requested behaviour, regression risk and real interfaces instead of asking an AI to “add tests.”
By AppLaunch Editorial · Reviewed 2026-08-25
Direct answer
Start with the acceptance behaviour, add a regression test that fails before the fix, then cover boundary and failure cases at the lowest useful level. Finish with the real integrated path when routing, data or external systems are involved.
What this means in plain English
Begin with the behaviour a person or system needs. Create a regression test that fails on the old bug, then cover empty, invalid, maximum and unauthorised cases. Use the smallest useful test level but finish with the real connected path when interfaces matter.
A large number of generated tests is not the goal. Tests should fail for meaningful broken behaviour and give enough information to fix it.
Which tests give confidence rather than coverage theatre?
| Regression | Proves the original defect or requirement |
|---|---|
| Boundary | Invalid, empty, maximum and unauthorized cases |
| Integration | Real component interfaces and user path |
A simple example
A file upload bug rejects names with spaces. The first test proves that exact filename fails before the fix and passes after. Additional tests cover empty files, oversized files and users without permission, followed by one browser upload.
What to do, step by step
1. Write observable acceptance criteria.
Start here before buying anything or changing several settings at once. It gives you a clear starting point based on regression: proves the original defect or requirement. Write the result down so you can compare it later.
2. Make the regression fail against old behaviour.
Use the same files, versions and settings that the real project will use. A quick test with an empty or different setup can look successful while completely missing the problem you are trying to solve.
3. Test error and rollback paths.
Try the busiest realistic situation, not the easiest one. Include the people, data, traffic or background work you genuinely expect, then watch for slowdowns and errors rather than relying on a single headline number.
4. Run the repository’s broad release gate.
Finish by checking the result against integration: real component interfaces and user path. Keep the old setting or release available until you know the change works and can be reversed safely.
One more useful tip
Temporarily run the regression against the old behaviour when possible. A test that already passed before the fix does not prove it protects the bug.
Common mistakes and how to avoid them
Testing implementation details only.
This gives a misleading or unsafe result because it leaves out regression. A better approach is to write observable acceptance criteria, then check the result before making the change permanent.
Generating snapshots no one reviews.
This gives a misleading or unsafe result because it leaves out boundary. A better approach is to make the regression fail against old behaviour, then check the result before making the change permanent.
Mocking the component whose contract is broken.
This gives a misleading or unsafe result because it leaves out integration. A better approach is to test error and rollback paths, then check the result before making the change permanent.
Words explained
- regression
- A feature that used to work but breaks after a change.
Quick checklist
- Write observable acceptance criteria.
- Make the regression fail against old behaviour.
- Test error and rollback paths.
- Run the repository’s broad release gate.
Common questions
What is the simple answer?
Start with the acceptance behaviour, add a regression test that fails before the fix, then cover boundary and failure cases at the lowest useful level. Finish with the real integrated path when routing, data or external systems are involved.
What should I check first?
Start with regression: proves the original defect or requirement. That is usually more useful than choosing from a marketing label or copying somebody else’s setting.
How can I make the change safely?
Write observable acceptance criteria. Then change one thing at a time, keep a backup or old version, and use the same real-world test after each change.
What is the easiest mistake to avoid?
Testing implementation details only. Avoiding that one mistake makes the rest of the comparison much more trustworthy.