You have a function, you need tests, and you're staring at a blank file. AI can generate a solid first draft of your unit test suite in under a minute — but only if you prompt it correctly. This walkthrough shows you exactly how to do it, step by step, with copy-paste prompts and real output patterns you can adapt immediately.
Why the Naive Prompt Fails
Most engineers start with something like "write tests for this function" and paste their code. The output is usually technically correct but shallow: happy-path only, no edge cases, no error conditions, no boundary values. It looks like coverage but isn't.
The fix isn't a fancier AI model — it's a better prompt structure.
Step 1: Frame the Function with Context
Before pasting code, tell the AI what the function is supposed to do, what it promises to callers, and what test framework you're using. One short paragraph of context doubles the quality of the output.
I have a TypeScript function that validates a user-submitted email address
before it's stored to the database. It should return true for valid emails
and false for invalid ones. I'm using Vitest with the `describe/it/expect`
pattern. No mocking is needed — the function is pure.
Here is the function:
[PASTE FUNCTION HERE]
Generate a comprehensive unit test suite. Cover: the happy path, boundary
cases (empty string, null, very long strings), malformed inputs
(missing @, multiple @, special characters), and any edge cases implied
by the implementation itself.
That last line — "edge cases implied by the implementation itself" — is the key instruction. It forces the model to read the actual logic rather than generating generic tests.
Step 2: Ask for a Test Plan Before the Code
For non-trivial functions, add one extra step: ask for the test plan first, review it, then ask for the implementation. This costs 30 seconds and catches gaps before they get baked into code.
Before writing any test code, list every test case you plan to cover for
the function above. Group them by: (1) valid inputs, (2) invalid inputs,
(3) boundary/edge cases, (4) error conditions. Use plain English, one
line per case. I'll confirm the list before you write any code.
Scan the list. You'll almost always spot a case the model missed — and more importantly, a case you would have missed too. Add it back in plain English before you proceed.
Step 3: Generate the Tests
Once the plan is approved, run the generation prompt:
Now write the full Vitest test suite based on the test plan above.
Requirements:
- One `describe` block named after the function
- One `it` block per test case, with a descriptive string that reads like a
sentence ("returns false when the input is an empty string")
- No external dependencies or mocks unless the function requires them
- If any test case requires a fixture or factory, define it at the top of
the describe block
- Add a one-line comment above any test that is non-obvious
The descriptive it strings matter. They're your documentation. When a test fails in CI at 2am, a string like "returns false when the input is an empty string" tells you exactly what broke without opening the file.
Step 4: Audit the Output for Coverage Gaps
Don't ship the AI output directly. Run this audit prompt against the generated suite:
Review the test suite you just wrote. Identify any of the following that
are missing or weakly covered:
1. Return value correctness (not just truthiness)
2. Side effects the function might have
3. Thrown exceptions or error types
4. Performance-sensitive paths (very large inputs)
5. Any assumption in the code that isn't tested
For each gap, either add a test case or explain why it's intentionally
excluded.
This is where the real value compounds. The model will often find its own blind spots when asked directly — things like checking the type of a return value, not just its truthiness, or confirming an exception has the right message, not just that it was thrown.
This pattern is one of the ones I've packaged into The AI Leverage Playbook: 50 Prompts & Workflows for Engineers — but the version above is enough to get value on its own.
Step 5: Parametrize Repetitive Cases
If the audit reveals many similar inputs that differ only in data, ask the model to refactor to a parametrized format:
Refactor any test cases that share the same assertion logic but differ
only in input data into a `it.each` table. Keep non-repetitive tests as
individual `it` blocks.
This cuts file length dramatically and makes it obvious when you need to add another row versus a whole new test.
The Full Prompt Order at a Glance
- Context prompt — framework, function purpose, constraints
- Test plan prompt — review before any code is written
- Generation prompt — structured output requirements
- Audit prompt — coverage gap check
- Refactor prompt — parametrize repetitive cases
Working through all five steps for a typical utility function takes about 10 minutes. The result is a test suite that would have taken 45–60 minutes to write by hand — and usually has better edge case coverage than the manual version.
One More Tip: Anchor to Your Existing Test Style
If your codebase already has tests, paste one existing test file alongside your prompt and add: "Match the style, naming conventions, and structure of the example test file below exactly." The AI will mirror your patterns, which means the output requires almost no style cleanup before review.
I break down one workflow like this every week in The AI Leverage Weekly — practical, no fluff, free. It's the fastest way to build a repeatable AI-assisted engineering practice. Subscribe: https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=long_w7