# How to Generate Unit Tests from a Function Using AI > Source: > Published: 2026-06-22 09:01:20+00:00 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. 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. 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. 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. 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. 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. 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. 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. 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](https://theaileverageweekly.beehiiv.com/subscribe?utm_source=devto&utm_medium=article&utm_campaign=long_w7)