Skip AI test generation when the requirement is unclear, when the test is really a specification, when you only want a coverage number, when the code under test is untrustworthy, or when the suite is already slow and flaky. In those cases, writing tests by hand or fixing the root problem pays back more.
1. The requirement is fuzzy
A model writes tests from whatever it reads. If the only source is the code, it restates the code. Google's review question for tests is whether they will fail when the code is broken, and a test derived from buggy code will not. Write down the intended behavior first, then decide whether generation helps.
2. The test is the specification
For core business rules, such as pricing, permissions or compliance logic, the tests are the record of what the rule should be. A person who understands the rule should write the key cases. A model can add variations afterward.
3. You just want the number
If the motive is to lift a coverage percentage, stop. Martin Fowler says coverage is of little use as a numeric statement of test quality and that targets invite people to hit them with weak tests. Generation makes that trap faster.
4. The code is hard to trust
Tests written against messy code can lock in strange behavior. If the code is likely wrong, review and fix it first. A refactor with a few carefully chosen characterization tests, written by a person who knows the intent, is better than a mass of generated ones.
5. The suite is already slow or flaky
More tests in a bad suite make it worse. Fowler's test pyramid points out that high level tests are brittle, expensive to write and slow to run. If a model adds more of those, your pipeline slows further. Fix the structure first.
Where generation does help
- Drafting boilerplate cases for pure functions from a clear spec.
- Suggesting edge cases you can accept or reject.
- Producing a unit test that reproduces a reported bug.
- Filling in table driven cases once the pattern is set.
Even then, check the output by breaking the code and watching the tests fail.
A quick filter
Before asking a model for tests, answer three questions: can I state the expected behavior in words, do I know at which level the test belongs, and will I read every test it writes? If any answer is no, slow down.
Quick check
Is AI test generation good for raising a coverage number?
It is quick at that, which is the danger. Coverage targets invite weak tests, so do not use generation to chase a number.
What should come before generating tests?
A clear statement of the expected behavior, so tests come from the requirement and not just from the code.
Sources
- Google Engineering Practices, What to look for in a code review
- Martin Fowler, Test Coverage
- Martin Fowler, Test Pyramid
Last reviewed: 19 October 2026.
