AI Test Generation: How to Generate Unit and Integration Tests

To generate useful tests with AI, choose targets with clear behaviour, give the AI the specification or acceptance criteria as well as the code, ask for normal, boundary and error cases with explicit expected values, keep mocks to real external boundaries and run the tests immediately. Then check strength, not just coverage: mutation testing or deliberately breaking the code shows whether tests can fail. Review every test for meaningful assertions before committing. Tests generated purely from current code are best reserved for characterizing legacy behaviour.

The broader testing strategy is in AI software testing. Characterization tests are a key step in legacy modernization, and agents that write tests as part of tasks are covered in AI coding agents.

Give the AI the specification, not just the code; name the framework and conventions; ask for explicit expected values; request boundary and error cases; and state what may be mocked. Ask it to explain which behaviours each test covers, which makes gaps visible.

Integration tests need realistic environments: test databases, containers for dependencies, seeded fixtures and API contracts. AI can draft fixtures, request sequences and assertions, but review setup and teardown carefully, keep tests isolated so they can run in parallel, and avoid calling real third-party services. Contract tests between services are a good target because specifications usually exist.

Line coverage says code ran, not that it was checked. Mutation testing tools change operators, constants and conditions and report which changes tests fail to catch; a low mutation score signals weak assertions. A cheaper check is to break the function deliberately and confirm tests fail. Use these on critical modules rather than everywhere.

Mutation testing tools such as Stryker automate this check for JavaScript, C# and Scala.

When code has no specification, generate tests that record current behaviour before changing it. Feed real inputs (anonymized samples, recorded requests) through the code, capture outputs and turn them into tests. Label them clearly as characterization tests: they protect against unintended change during refactoring, and differences found later become explicit decisions. See AI legacy code modernization.

API contracts are a strong source for generated tests because the expected behaviour is written down. From an OpenAPI or similar specification, AI can draft tests for status codes, required fields, error responses and boundary values on both provider and consumer sides. Run them in CI so a change that breaks a consumer is caught before deployment.

Example-based tests check specific inputs. Property-based tests check rules that should hold for many inputs, such as 'sorting twice gives the same result as sorting once' or 'a refund never exceeds the original payment'. AI is good at proposing properties from code and requirements, and property testing libraries then generate hundreds of inputs automatically.

AI can also enumerate edge cases people forget: empty collections, maximum lengths, time zone boundaries, leap years, Unicode, concurrency and permissions. Ask for a list of edge cases first, review it, then generate tests for the ones that matter. This keeps you in control of what is tested rather than accepting whatever the model chose.

Libraries such as Hypothesis for Python implement this approach.

Generated tests are still code your team maintains. Hold them to the same standards: clear names that describe behaviour, minimal mocking, no duplicated setup and no assertions on implementation details. Delete generated tests that add no protection; a large suite of weak tests slows CI and hides the important failures.

When requirements change, update tests deliberately rather than regenerating them to match new code, which would simply confirm whatever the code now does. Mutation testing on critical modules shows whether tests detect real faults. The wider testing strategy is in AI software testing.

AI can generate browser tests from user stories or from recorded sessions, producing scripts for frameworks such as Playwright or Cypress. Generated end-to-end tests often rely on fragile selectors and fixed waits. Instruct the generator to use accessible roles, labels and test IDs, and to wait for conditions rather than time.

Keep end-to-end suites small and focused on critical journeys such as sign-up, checkout and key workflows, because they are slow and costly to maintain. Push detailed logic testing down to unit and integration levels. Triage and flaky test handling are covered in AI software testing.

AI makes it easy to hit coverage targets with tests that execute code without checking it. If coverage is a goal, pair it with mutation score on important modules or with reviews of assertion quality. Coverage shows what code ran; only assertions show what was verified.

An illustrative scenario, not a client case: a team generates tests for a discount engine from code alone and reaches high coverage, but a production bug in stacked discounts slips through because the tests assert the buggy current output. Regenerating from the promotions specification, with expected values per rule, exposes the bug immediately.

Good AI test generation starts from specifications, uses explicit expectations and minimal mocks, and proves tests can fail. Related: AI software testing and legacy modernization.