Generating Tests & Edge Cases
Prompt the model to generate meaningful tests, including the edge cases it would otherwise skip, in your framework and style.
TL;DR
- AI is strong at generating tests, especially the edge cases humans skip, if you ask for them by name.
- Specify the framework, the style, and that tests should assert behavior, not implementation.
- Review generated tests: a test that passes against buggy code is worse than no test.
Ask For Coverage
Name The CategoriesSpell out the kinds of case you want so none are skipped.
"Cover: happy path, empty, null,
boundaries, invalid input, errors."Boundaries ExplicitlyCall out the edges where bugs hide, off-by-one, min/max, zero.
"Test n = 0, n = 1, and n = max."Error PathsAsk for tests that assert the right errors are thrown.
"Assert it throws on n < 1 with the
exact message."Match Your Suite
Name The FrameworkState the test runner and version so syntax matches.
"Vitest, TypeScript, describe/it,
expect assertions."Template TestPaste one existing test and ask new ones to mirror it.
"Match the structure and naming of
this existing test: <paste>"Same HelpersReuse your fixtures and factories instead of ad-hoc setup.
"Use the existing makeUser() factory."Behavior Over Internals
Assert OutputsCheck what the code returns or does, not how it does it.
expect(total).toBe(1500)
// not: expect(calc).toHaveBeenCalled()Avoid Over-MockingMock only true boundaries; over-mocking tests the mocks, not the code.
Mock the network, not your own
pure functions.Readable NamesAsk for test names that describe the behavior under test.
it('returns $0.00 for an empty cart')Verify The Tests
Check AssertionsConfirm each expected value is actually correct, not just current.
Is toBe(1500) the RIGHT answer,
or just what the code outputs?Mutation CheckBreak the code on purpose; a good test should then fail.
Introduce a bug -> test goes red?
If not, the test is weak.Run ThemExecute the suite; generated tests sometimes do not even run.
npm test # they pass AND are meaningfulTips
- List the categories you want: happy path, empty, null, boundaries, errors, and concurrency where relevant.
- Give one existing test as a style template so new tests match your framework and assertions.
Warnings
- Models can write tests that assert whatever the current (possibly buggy) code does; verify the assertions are correct.
- Tests coupled to implementation details break on every refactor; ask for behavior-focused assertions.
In Practice
A test-generation prompt that names the framework, supplies a style template, and demands specific edge cases with behavior-focused assertions, then you verify the assertions are actually correct.
- The prompt pins the framework and points at an existing test as the template.
- It lists the edge-case categories explicitly so the happy path is not the only coverage.
- It asks for behavior assertions on outputs, not internal call checks.
- A reminder to use real expected values keeps the tests honest, not code-mirroring.
Write tests for `formatMoney(cents: number): string`.
Framework: Vitest + TypeScript, describe/it, expect.
Match the style of this existing test:
<paste one test file>
Cover these cases:
- 0 -> "$0.00"
- 1500 -> "$15.00"
- negative: -4250 -> "-$42.50"
- large: 100000000 -> grouped with commas
- throws on non-integer input
Assert the returned strings (behavior), not internal
calls. Use the correct expected values above, not
whatever the current code happens to output.
Return the test file only.FAQ
Ask for them explicitly and by category: empty inputs, null and undefined, zero and negative numbers, boundary values, very large inputs, invalid types, and error conditions. Models cover these well when prompted, but default to the happy path if you do not ask.
Name the framework and version (Vitest, Jest, pytest) and paste one existing test as a template. Say 'match this structure, naming, and assertion style'. That yields tests that fit your suite instead of a generic format.
Because a model can write tests that simply assert whatever the code currently does, bugs included. A green suite then gives false confidence. Check that each assertion reflects the intended behavior, not just the observed behavior.
Behavior. Ask for tests that assert observable outputs and side effects, not internal calls or private state. Behavior tests survive refactors; implementation-coupled tests break whenever you reorganize the code.