We earn commissions when you shop through the links below.
If you’ve ever stared at a function you just wrote and dreaded the thought of hand-crafting a dozen test cases, you’re not alone. Knowing how to use AI to generate unit tests is one of the most practical skills a developer can pick up right now — it cuts the boring parts of TDD down to almost nothing and lets you focus on actually writing good software.
In this guide I’ll walk you through my real workflow: which tools work best, how to prompt them effectively, what to watch out for, and how to integrate AI-generated tests into your CI pipeline without losing confidence in your test suite.
Why AI-Generated Unit Tests Actually Work
Unit tests are a perfect target for AI assistance because they follow predictable patterns. Given a function signature and a body, a good language model can infer edge cases, boundary conditions, happy paths, and error states with surprising accuracy. The model has seen millions of test files — it knows what a good test looks like.
The catch is that AI still generates plausible-looking nonsense sometimes. Your job shifts from writing tests to reviewing and curating them. That’s a much faster loop, and it’s still your engineering judgment keeping quality high.
The Best Tools for the Job
There are three main approaches in 2026:
- AI-native editors — Cursor is my daily driver here. It understands your entire codebase, not just the open file, so generated tests reference real imports, mocks, and fixtures.
- Chat-based assistants — Claude, GPT-4o, and Gemini all work fine for generating tests when you paste in a function. Good for one-offs, less good for large codebases.
- Dedicated testing tools — CodiumAI (now Qodo), Diffblue (for Java), and similar tools are purpose-built for test generation and can auto-run tests to verify they pass.
For most web developers, Cursor gives the best balance of context-awareness and flexibility. It uses your existing test setup — Jest, Vitest, PHPUnit, pytest — rather than inventing its own conventions.
How to Prompt AI for Unit Tests Effectively
Bad prompts produce bad tests. Here’s the difference:
Weak prompt: “Write tests for this function.”
Strong prompt: “Write Jest unit tests for the function below. Use the existing mock setup in __mocks__/db.js. Cover: the happy path, an empty input, a null input, and a case where the database throws. Use describe and it blocks. Don’t test implementation details.”
Specificity is everything. Tell the AI which testing framework you use, what mocking utilities are available, and what behaviors matter most.
Real Example: Generating Tests for a JavaScript Utility Function
Here’s a simple function I want to test:
// src/utils/formatPrice.js
export function formatPrice(amount, currency = 'USD') {
if (amount === null || amount === undefined) {
throw new Error('Amount is required');
}
if (typeof amount !== 'number' || isNaN(amount)) {
throw new TypeError('Amount must be a valid number');
}
return new Intl.NumberFormat('en-US', {
style: 'currency',
currency,
}).format(amount);
}
I paste this into Cursor with the prompt: “Write Vitest unit tests for this function. Cover happy paths, edge cases, and error conditions. Use describe/it/expect. No mocking needed.”
Here’s what it produces (lightly edited by me):
// src/utils/formatPrice.test.js
import { describe, it, expect } from 'vitest';
import { formatPrice } from './formatPrice';
describe('formatPrice', () => {
describe('happy path', () => {
it('formats a whole number in USD by default', () => {
expect(formatPrice(10)).toBe('$10.00');
});
it('formats a decimal number', () => {
expect(formatPrice(9.99)).toBe('$9.99');
});
it('formats with a different currency', () => {
expect(formatPrice(100, 'EUR')).toMatch(/100/);
});
it('formats zero correctly', () => {
expect(formatPrice(0)).toBe('$0.00');
});
it('formats negative amounts', () => {
expect(formatPrice(-5)).toBe('-$5.00');
});
});
describe('error cases', () => {
it('throws when amount is null', () => {
expect(() => formatPrice(null)).toThrow('Amount is required');
});
it('throws when amount is undefined', () => {
expect(() => formatPrice(undefined)).toThrow('Amount is required');
});
it('throws a TypeError when amount is a string', () => {
expect(() => formatPrice('ten')).toThrow(TypeError);
});
it('throws a TypeError when amount is NaN', () => {
expect(() => formatPrice(NaN)).toThrow(TypeError);
});
});
});
That’s a solid first pass. I reviewed it, noticed the EUR test uses toMatch instead of an exact value (intentional — locale formatting varies), and shipped it. Total time: about 90 seconds.
Handling More Complex Cases
The real power of knowing how to use AI to generate unit tests shows up when you’re dealing with async functions, database calls, or API integrations. The key is giving the AI enough context about your mock setup.
In Cursor, I’ll often open the relevant mock file alongside the source file, then use Ctrl+K with a prompt like: “Generate tests using the existing vi.mock pattern in this file. The db.findUser call should be mocked to return a fixture user object.” Because Cursor reads both files, it generates tests that actually import and use your existing mocking infrastructure rather than inventing new ones.
For teams that want a more structured approach, services like Udemy have solid courses on test-driven development that pair well with AI tooling — they give you the mental model for what to test, and AI handles the tedium of writing it.
Quality Control: Don’t Skip This Step
AI-generated tests have a few recurring failure modes:
- False confidence — Tests that always pass because they assert the wrong thing. Common with
toBeTruthy()instead of a specific value. - Testing the implementation — Tests that break whenever you refactor, even if behavior stays the same.
- Missing real edge cases — AI covers obvious edges but might miss domain-specific ones only you know about.
- Hallucinated APIs — Occasionally the AI will invent a method that doesn’t exist in your version of a library.
My review checklist for AI-generated tests:
- Run them. Do they pass? Do any fail for unexpected reasons?
- Temporarily break the source function. Do the tests catch it?
- Read each assertion. Does it actually verify meaningful behavior?
- Delete any test that feels like padding with no real assertion value.
Integrating Into Your Workflow
Here’s how I’ve structured AI test generation into my daily dev loop:
- Write the function first. AI tests work best when there’s real code to analyze.
- Generate tests immediately. Don’t let untested code accumulate.
- Review and trim. Spend 2-5 minutes on quality control per test file.
- Add domain-specific cases. The AI doesn’t know your business rules — you do.
- Commit together. Source and tests in the same commit keeps history clean.
This workflow means I’m writing maybe 20% of my test code manually. The rest is AI-assisted and human-reviewed. Coverage goes up, time goes down, and the tests are actually meaningful because I’m curating rather than grinding.
When AI Struggles With Test Generation
Knowing how to use AI to generate unit tests also means knowing its limits. AI performs worse when:
- The function has complex side effects with no clear return value
- Tests require deep knowledge of an internal API or legacy system
- You’re testing UI interactions that require careful event simulation
- The codebase has unusual conventions the model hasn’t seen
In these cases, treat AI output as a scaffold — a structure to fill in rather than a finished product.
Final Thoughts
Learning how to use AI to generate unit tests isn’t about removing yourself from the testing process — it’s about removing the tedious parts so you can focus on the parts that require your expertise. The AI generates volume; you provide judgment.
Start with a tool like Cursor, give it real context, review everything it produces, and you’ll find your test coverage climbing while your time spent on boilerplate drops dramatically. That’s a trade worth making every single time.