Write unit tests for the code and behavior below. Code under test: [CODE UNDER TEST] Language, test framework, and project conventions: [TEST STACK] Expected behavior and public contract: [EXPECTED BEHAVIOR] Existing test helpers, fixtures, mocks, or test examples: [PROJECT CONTEXT] Known bugs, boundary cases, or risk areas: [RISK AREAS]
First, identify the unit boundary: what belongs in these tests and what should be replaced with a fake, stub, or mock. Then produce: 1. A short test plan mapping each test to one contract, branch, boundary, or failure mode. 2. Complete, runnable test code in [TEST STACK], using the project’s naming, setup, and assertion conventions where supplied. 3. A brief explanation after each test describing the behavior it protects and why its inputs matter. Test observable outcomes, not private implementation details. Cover the normal case, empty or missing inputs where the contract permits them, minimum and maximum boundaries, invalid input or error behavior, and at least one case that could reveal an off-by-one, mutation, ordering, timezone, or dependency failure if relevant. Use deterministic clocks, random values, and external dependencies. Mock only collaborators outside the unit boundary; do not mock the behavior being tested. Do not invent APIs, types, return values, or project helpers. If the supplied contract and code disagree, flag the conflict instead of guessing. Before answering, check that every test has a distinct purpose and that each assertion follows from [EXPECTED BEHAVIOR]. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [CODE UNDER TEST] | Paste the function, class, module, or relevant code you want covered. | export function paginate<T>(items: T[], page: number, size: number) { if (page < 1 || size < 1) throw new RangeError('page and size must be positive'); return items.slice((page - 1) * size, page * size); } |
| [TEST STACK] | Name the language, test framework, and any repository conventions such as Jest, pytest, or xUnit. | TypeScript, Vitest, existing tests use describe/it and expect().toEqual(). |
| [EXPECTED BEHAVIOR] | Describe the documented inputs, outputs, errors, and rules the code must satisfy. | Pages are one-based. Return an empty array when the requested page starts beyond the items. Reject zero and negative page or size values. |
| [PROJECT CONTEXT] | Paste relevant existing tests, fixtures, helper APIs, or dependency interfaces. | No helpers needed; this is a pure utility module. |
| [RISK AREAS] | List known bugs, important edge cases, or scenarios most likely to regress. | Last partial page; page exactly after the final item; inputs must not be mutated. |
How to use
- Paste the implementation, then state the external contract rather than only saying what the code appears to do.
- Include one or two existing tests if the repository has a local style or fixture pattern.
- Check that generated imports, helper names, and error messages really exist in your project.
- Follow up with: "Now add only the missing tests for the uncovered branches in this coverage report: [REPORT]."
Variations
Bug regression test
Use after reproducing a defect and before shipping its fix.
Create a minimal regression test for this bug. Bug report: [BUG REPORT] Failing input and actual result: [REPRODUCTION] Correct behavior: [EXPECTED RESULT] Code and test stack: [CODE AND TEST STACK] Write one focused failing test first, then the expected passing version if the fix is already present. Keep the setup minimal and test the public behavior that a user experienced. Explain which assertion would have caught the bug. Do not infer facts not in the report. Check that the test fails on the described old behavior and does not merely duplicate an existing happy-path test.
Parameterized cases
Use when one rule must hold across many input combinations.
Turn this behavior matrix into parameterized unit tests. Function or endpoint: [CODE] Test framework: [TEST FRAMEWORK] Behavior matrix: [INPUT OUTPUT CASES] Exceptions and invalid cases: [ERROR CASES] Produce runnable table-driven tests with descriptive case names. Separate successful cases from error cases when that makes failures easier to diagnose. Use literal expected values, not calculations that repeat the implementation’s logic. Do not add rows that are unsupported by the supplied contract. Before answering, verify every matrix row appears once and each case has a clear expected outcome.
Mock boundaries
Use when a unit calls a database, API, queue, clock, or other collaborator.
Design unit tests for this service while isolating its external collaborators. Service code: [SERVICE CODE] Collaborator interfaces: [DEPENDENCIES] Required behavior: [CONTRACT] Test stack: [TEST STACK] State which collaborators to fake or mock and why. Then write runnable tests for the service’s decisions, inputs passed to collaborators, error translation, retries, and returned result. Avoid asserting incidental call order unless it is contractual. Do not mock internal methods just to make a test pass. Check that every mock represents a real interface method and that the tests would fail if the service made the wrong decision.
Tips
- Write the contract in terms of observable behavior; tests built only from implementation branches tend to preserve the same bug.
- Use boundary values around domain limits, such as 0, 1, the maximum, and one value on either side, rather than a long list of arbitrary examples.
- Keep network, database, time, randomness, and filesystem behavior deterministic so a failure identifies a code change rather than the environment.
- A generated test that asserts a mock was called can be useful, but it should also assert the resulting behavior when that behavior is visible to callers.
FAQ
Should AI-generated unit tests target 100% coverage?
No. Coverage can reveal untested code, but meaningful tests target contracts, risky branches, boundaries, and error behavior. A line can be covered without being usefully checked.
When should I use mocks in generated tests?
Mock dependencies outside the unit, such as HTTP clients or repositories. Do not mock the unit’s own logic or assertions become disconnected from its real behavior.
Can I paste a whole file?
Yes, but include the specific public behavior you need protected. For a large file, start with one exported unit so the test plan stays reviewable.