Use this guide when you have a working project with few or no tests and want to change it safely. Have the project running locally, a testing tool installed for your language and version control set up.
Step by step
Choose what to test first
List the most important and most fragile parts of your code, such as payment calculations, data imports or login. Start with one area that would cause real harm if it broke. Testing everything at once is overwhelming and rarely finished.
Capture current behaviour
Run the code with typical inputs and write down what it actually does, including outputs and side effects. Tests that record current behaviour, sometimes called characterisation tests, protect you from accidental changes even if the behaviour is not perfect. Note anything that looks like a bug separately rather than fixing it now.
Ask the AI to draft tests
Give the assistant the function or module, the inputs and outputs you recorded and the testing tool you use. Ask for tests covering normal cases, edge cases and error handling. Ask it to avoid changing the code under test.
Check the tests can fail
Run the tests and confirm they pass. Then deliberately break the code, for example by changing a calculation, and check that at least one test fails. A test that never fails is not protecting you.
Make tests run automatically
Add a single command that runs all tests, and document it in your README. If you use a code hosting service, set up continuous integration to run the tests on every push. Commit the tests with a clear message.
Expand coverage gradually
Each time you change or fix part of the code, add tests for that area first. Over time, the most important parts of your project become protected. Review your list of fragile areas every few weeks and pick the next one.
Ready-to-use checklist
- Testing tool installed
- Most important area chosen
- Current behaviour recorded
- Tests drafted and reviewed
- Tests fail when code is broken
- One command runs all tests
- Tests running in CI if available
- List of next areas to test
Practical tips
- Name tests after the behaviour they check, such as rejects empty email address, so failures are easy to understand.
- Keep test data small and made up, never copied from real customer records.
- If code is hard to test, that is often a sign it needs to be split into smaller functions later.
Common problems
The AI-written tests all pass even when I break the code.
The tests are probably checking too little, such as only that the function runs. Ask the assistant to add specific assertions about outputs, and repeat the deliberate-break check.
The code talks to a database or outside service, which makes testing hard.
Use a separate test database or replace the outside service with a simple fake in your tests. Ask the AI to show how to do this with your testing tool, and check the approach against its documentation.
I found a bug while writing tests.
Record it, write a test that shows the bug and then decide whether to fix it now or later. Keeping the discovery separate from the testing work makes each change easier to review.