Testing with AI

Why Testing Is Different with AI

Testing is where most developers shortcut — not because they don't value it, but because writing tests is tedious. Describing what should happen, again, in a different syntax, for every path through every function. It's the part that feels like paperwork.

AI removes that friction almost entirely. Given a function, AI can generate a full test suite in seconds. Given a description of what could go wrong, it generates edge cases you wouldn't have thought of. Given a failing test, it explains why it's failing and suggests a fix.

The result isn't just faster testing. It's better testing — because the cost of writing an additional test case drops to near zero, developers stop skipping the awkward paths. The coverage improves not because it's enforced, but because it's no longer a burden.

Part 1: Unit Tests

Unit tests are AI's strongest suit. The context is small and self-contained: a function goes in, a test suite comes out. The pattern is so reliable that it should be the first thing you reach for.

The Basic Prompt

Start with the simplest possible ask: paste the function, ask for tests.

export function slugify(text: string): string {
  return text
    .toLowerCase()
    .trim()
    .replace(/[^\w\s-]/g, '')
    .replace(/[\s_-]+/g, '-')
    .replace(/^-+|-+$/g, '');
}

AI produces a complete suite. Here's what good output looks like:

import { describe, it, expect } from 'vitest';
import { slugify } from './slugify';

describe('slugify', () => {
  // Normal inputs
  it('converts a basic phrase to a slug', () => {
    expect(slugify('Hello World')).toBe('hello-world');
  });

  it('handles multiple words', () => {
    expect(slugify('The Quick Brown Fox')).toBe('the-quick-brown-fox');
  });

  // Whitespace handling
  it('trims leading and trailing whitespace', () => {
    expect(slugify('  hello world  ')).toBe('hello-world');
  });

  it('collapses multiple spaces into one hyphen', () => {
    expect(slugify('hello   world')).toBe('hello-world');
  });

  // Special characters
  it('removes special characters', () => {
    expect(slugify('Hello, World!')).toBe('hello-world');
  });

  it('removes characters that are not word chars, spaces, or hyphens', () => {
    expect(slugify('café & crème')).toBe('caf-crme');
  });

  // Hyphen handling
  it('replaces underscores with hyphens', () => {
    expect(slugify('hello_world')).toBe('hello-world');
  });

  it('removes leading and trailing hyphens', () => {
    expect(slugify('-hello world-')).toBe('hello-world');
  });

  it('collapses consecutive hyphens', () => {
    expect(slugify('hello---world')).toBe('hello-world');
  });

  // Edge cases
  it('returns empty string for empty input', () => {
    expect(slugify('')).toBe('');
  });

  it('returns empty string for whitespace-only input', () => {
    expect(slugify('   ')).toBe('');
  });

  it('returns empty string for special characters only', () => {
    expect(slugify('!@#$%')).toBe('');
  });

  it('handles a single word', () => {
    expect(slugify('Hello')).toBe('hello');
  });

  it('preserves numbers', () => {
    expect(slugify('chapter 1 intro')).toBe('chapter-1-intro');
  });
});

Generating Edge Cases Explicitly

For complex functions, ask for edge cases as a separate step before writing tests. This surfaces assumptions you didn't know you had.

export function calculateDiscount(
  price: number,
  quantity: number,
  couponCode?: string
): number

A good AI response surfaces cases like: negative price, zero quantity, floating point precision at exact tier boundaries, an empty string vs. undefined coupon, expired coupons if the function checks dates, integer overflow for very large quantities. Many of these you'd miss in a first pass.

Testing Pure vs. Impure Functions

Pure functions (same input → same output, no side effects) test cleanly with the pattern above. Impure functions — ones that read files, make network calls, write to a database — need mocks. Tell AI which category you're in:

import { sendEmail } from './email';

export async function notifyUserOnSignup(email: string, name: string) {
  if (!email.includes('@')) throw new Error('Invalid email');
  await sendEmail({
    to: email,
    subject: 'Welcome to the platform',
    body: `Hi ${name}, thanks for signing up!`,
  });
}

import { describe, it, expect, vi, beforeEach } from 'vitest';
import { notifyUserOnSignup } from './notify';
import * as emailModule from './email';

describe('notifyUserOnSignup', () => {
  beforeEach(() => {
    vi.restoreAllMocks();
  });

  it('calls sendEmail with correct arguments', async () => {
    const sendEmailSpy = vi.spyOn(emailModule, 'sendEmail').mockResolvedValue(undefined);

    await notifyUserOnSignup('user@example.com', 'Alice');

    expect(sendEmailSpy).toHaveBeenCalledOnce();
    expect(sendEmailSpy).toHaveBeenCalledWith({
      to: 'user@example.com',
      subject: 'Welcome to the platform',
      body: 'Hi Alice, thanks for signing up!',
    });
  });

  it('throws on invalid email', async () => {
    await expect(notifyUserOnSignup('notanemail', 'Alice'))
      .rejects.toThrow('Invalid email');
  });

  it('does not call sendEmail when email is invalid', async () => {
    const sendEmailSpy = vi.spyOn(emailModule, 'sendEmail').mockResolvedValue(undefined);

    await expect(notifyUserOnSignup('notanemail', 'Alice')).rejects.toThrow();
    expect(sendEmailSpy).not.toHaveBeenCalled();
  });

  it('propagates errors from sendEmail', async () => {
    vi.spyOn(emailModule, 'sendEmail').mockRejectedValue(new Error('SMTP timeout'));

    await expect(notifyUserOnSignup('user@example.com', 'Alice'))
      .rejects.toThrow('SMTP timeout');
  });
});

Part 2: Integration Tests

Integration tests verify that multiple pieces work together — a route handler reading from a real database, an API endpoint returning the right status code, a service composing two repositories. They catch the bugs unit tests miss.

They're also the tests developers skip most often, because they require setup. AI makes that setup fast.

Testing an API Route

The most common integration test pattern: HTTP request in, database state or response body out. Give AI the route, the database schema, and your test framework:

import { describe, it, expect, beforeEach, afterEach } from 'vitest';
import request from 'supertest';
import Database from 'better-sqlite3';
import { createApp } from '../src/app';
import { migrate } from '../src/db/migrations';

let db: Database.Database;
let app: ReturnType<typeof createApp>;

beforeEach(() => {
  db = new Database(':memory:');
  migrate(db);
  app = createApp(db);
});

afterEach(() => {
  db.close();
});

describe('POST /api/users/register', () => {
  const validPayload = {
    email: 'alice@example.com',
    password: 'securepassword',
  };

  it('creates a user and returns 201 with user data', async () => {
    const res = await request(app).post('/api/users/register').send(validPayload);

    expect(res.status).toBe(201);
    expect(res.body).toMatchObject({
      email: 'alice@example.com',
    });
    expect(res.body.id).toBeDefined();
    expect(res.body.createdAt).toBeDefined();
    expect(res.body.password).toBeUndefined(); // never leak password
  });

  it('returns 400 when email is already registered', async () => {
    await request(app).post('/api/users/register').send(validPayload);
    const res = await request(app).post('/api/users/register').send(validPayload);

    expect(res.status).toBe(400);
    expect(res.body.error).toMatch(/already/i);
  });

  it('returns 422 when email format is invalid', async () => {
    const res = await request(app)
      .post('/api/users/register')
      .send({ email: 'notanemail', password: 'securepassword' });

    expect(res.status).toBe(422);
    expect(res.body.error).toBeDefined();
  });

  it('returns 422 when password is too short', async () => {
    const res = await request(app)
      .post('/api/users/register')
      .send({ email: 'alice@example.com', password: 'short' });

    expect(res.status).toBe(422);
    expect(res.body.error).toBeDefined();
  });

  it('does not store plaintext password in database', async () => {
    await request(app).post('/api/users/register').send(validPayload);

    const user = db.prepare('SELECT * FROM users WHERE email = ?').get(validPayload.email) as any;
    expect(user.password_hash).not.toBe(validPayload.password);
    expect(user.password_hash).toMatch(/^\$2[aby]\$/); // bcrypt prefix
  });
});

Writing Test Helpers with AI

Repeated setup code belongs in a helper. Ask AI to generate it:

import Database from 'better-sqlite3';
import request from 'supertest';
import { createApp } from '../src/app';
import { migrate } from '../src/db/migrations';

export function createTestDb() {
  const db = new Database(':memory:');
  migrate(db);
  return db;
}

export function createTestApp(db: Database.Database) {
  return createApp(db);
}

const defaultUser = {
  email: 'test@example.com',
  password: 'testpassword123',
  name: 'Test User',
};

export async function registerUser(
  app: Express.Application,
  overrides: Partial<typeof defaultUser> = {}
) {
  const payload = { ...defaultUser, ...overrides };
  const res = await request(app).post('/api/users/register').send(payload);
  return res.body;
}

export async function loginUser(
  app: Express.Application,
  email = defaultUser.email,
  password = defaultUser.password
): Promise<string> {
  const res = await request(app).post('/api/auth/login').send({ email, password });
  return res.body.token;
}

export function authHeader(token: string) {
  return { Authorization: `Bearer ${token}` };
}

With helpers in place, subsequent test files become clean and expressive:

import { beforeEach, afterEach, describe, it, expect } from 'vitest';
import request from 'supertest';
import { createTestDb, createTestApp, registerUser, loginUser, authHeader } from './helpers';

let db, app, token;

beforeEach(async () => {
  db = createTestDb();
  app = createTestApp(db);
  await registerUser(app);
  token = await loginUser(app);
});

afterEach(() => db.close());

describe('POST /api/bookmarks', () => {
  it('creates a bookmark for the authenticated user', async () => {
    const res = await request(app)
      .post('/api/bookmarks')
      .set(authHeader(token))
      .send({ url: 'https://example.com', title: 'Example' });

    expect(res.status).toBe(201);
    expect(res.body.data.url).toBe('https://example.com');
  });

  it('returns 401 without a token', async () => {
    const res = await request(app)
      .post('/api/bookmarks')
      .send({ url: 'https://example.com', title: 'Example' });

    expect(res.status).toBe(401);
  });
});

Part 3: TDD with AI

Test-Driven Development — write the test before the implementation — pairs surprisingly well with AI. The classic complaint about TDD is that writing tests for non-existent code is mentally exhausting. With AI, you describe the behavior in a prompt, get the test, and then ask for the implementation that passes it.

The Red-Green-Refactor Loop with AI

Here's the workflow. You're building a rate limiter:

Step 1 — Describe the behavior, get the test:

import { describe, it, expect, beforeEach, vi, afterEach } from 'vitest';
import { RateLimiter } from './rateLimiter';

describe('RateLimiter', () => {
  beforeEach(() => vi.useFakeTimers());
  afterEach(() => vi.useRealTimers());

  it('allows requests under the limit', () => {
    const limiter = new RateLimiter({ limit: 3, windowMs: 1000 });

    expect(limiter.check('user-1')).toEqual({ allowed: true });
    expect(limiter.check('user-1')).toEqual({ allowed: true });
    expect(limiter.check('user-1')).toEqual({ allowed: true });
  });

  it('blocks when the limit is reached', () => {
    const limiter = new RateLimiter({ limit: 2, windowMs: 1000 });

    limiter.check('user-1');
    limiter.check('user-1');
    const result = limiter.check('user-1');

    expect(result.allowed).toBe(false);
    expect((result as any).retryAfter).toBeGreaterThan(0);
  });

  it('tracks different keys independently', () => {
    const limiter = new RateLimiter({ limit: 1, windowMs: 1000 });

    expect(limiter.check('user-1')).toEqual({ allowed: true });
    expect(limiter.check('user-2')).toEqual({ allowed: true }); // different key
  });

  it('resets count after the window expires', () => {
    const limiter = new RateLimiter({ limit: 2, windowMs: 1000 });

    limiter.check('user-1');
    limiter.check('user-1');
    expect(limiter.check('user-1').allowed).toBe(false);

    vi.advanceTimersByTime(1001);

    expect(limiter.check('user-1')).toEqual({ allowed: true });
  });

  it('returns retryAfter in milliseconds', () => {
    const limiter = new RateLimiter({ limit: 1, windowMs: 5000 });

    limiter.check('user-1');
    vi.advanceTimersByTime(2000);
    const result = limiter.check('user-1') as { allowed: false; retryAfter: number };

    expect(result.allowed).toBe(false);
    expect(result.retryAfter).toBeLessThanOrEqual(3000);
    expect(result.retryAfter).toBeGreaterThan(0);
  });
});

Step 2 — Run the tests (they fail — that's correct).

Step 3 — Ask for the implementation that passes them:

interface RateLimiterOptions {
  limit: number;
  windowMs: number;
}

interface RateLimiterEntry {
  count: number;
  windowStart: number;
}

type CheckResult =
  | { allowed: true }
  | { allowed: false; retryAfter: number };

export class RateLimiter {
  private store = new Map<string, RateLimiterEntry>();

  constructor(private options: RateLimiterOptions) {}

  check(key: string): CheckResult {
    const now = Date.now();
    const entry = this.store.get(key);

    if (!entry || now - entry.windowStart >= this.options.windowMs) {
      this.store.set(key, { count: 1, windowStart: now });
      return { allowed: true };
    }

    if (entry.count < this.options.limit) {
      entry.count++;
      return { allowed: true };
    }

    const retryAfter = this.options.windowMs - (now - entry.windowStart);
    return { allowed: false, retryAfter };
  }
}

Step 4 — Run the tests again. They pass. If they don't, paste the failure output back into AI and ask it to fix the implementation.

Part 4: Mocking and Isolation

Good tests are isolated — they test one thing and don't break because something unrelated changed. Mocking is what makes isolation possible. It's also the part developers spend the most time on. AI handles it well if you're explicit about what you're mocking and why.

Mocking Modules

import { userRepo } from '../db/userRepo';

export async function getUserProfile(userId: string) {
  const user = await userRepo.findById(userId);
  if (!user) throw new Error('User not found');
  return { id: user.id, name: user.name, email: user.email };
}

import { describe, it, expect, vi, beforeEach } from 'vitest';
import { getUserProfile } from './getUserProfile';

vi.mock('../db/userRepo', () => ({
  userRepo: {
    findById: vi.fn(),
  },
}));

import { userRepo } from '../db/userRepo';

describe('getUserProfile', () => {
  beforeEach(() => {
    vi.clearAllMocks();
  });

  it('returns formatted profile when user exists', async () => {
    const mockUser = { id: '123', name: 'Alice', email: 'alice@example.com', passwordHash: 'x' };
    vi.mocked(userRepo.findById).mockResolvedValue(mockUser);

    const result = await getUserProfile('123');

    expect(result).toEqual({
      id: '123',
      name: 'Alice',
      email: 'alice@example.com',
    });
  });

  it('calls userRepo.findById with the correct userId', async () => {
    vi.mocked(userRepo.findById).mockResolvedValue(
      { id: '456', name: 'Bob', email: 'bob@example.com', passwordHash: 'x' }
    );

    await getUserProfile('456');

    expect(userRepo.findById).toHaveBeenCalledWith('456');
  });

  it('throws when user is not found', async () => {
    vi.mocked(userRepo.findById).mockResolvedValue(null);

    await expect(getUserProfile('nonexistent')).rejects.toThrow('User not found');
  });

  it('does not expose passwordHash in the result', async () => {
    vi.mocked(userRepo.findById).mockResolvedValue(
      { id: '123', name: 'Alice', email: 'alice@example.com', passwordHash: 'secret' }
    );

    const result = await getUserProfile('123');

    expect(result).not.toHaveProperty('passwordHash');
  });
});

Generating a Full Mock from a Type

When you have a complex interface and need a realistic-looking fake for tests, paste the type and ask for a factory:

interface User {
  id: string;
  email: string;
  name: string;
  role: 'admin' | 'member' | 'viewer';
  createdAt: Date;
  lastLoginAt: Date | null;
  isEmailVerified: boolean;
}

import { User } from '../src/types';

let idCounter = 0;

export function createMockUser(overrides: Partial<User> = {}): User {
  idCounter++;
  return {
    id: `user-${idCounter}`,
    email: `user${idCounter}@example.com`,
    name: `Test User ${idCounter}`,
    role: 'member',
    createdAt: new Date('2024-01-01T00:00:00Z'),
    lastLoginAt: null,
    isEmailVerified: true,
    ...overrides,
  };
}

// Reset between test runs if needed
export function resetFactoryCounters() {
  idCounter = 0;
}

Usage in tests becomes readable and explicit:

const admin = createMockUser({ role: 'admin', isEmailVerified: true });
const unverified = createMockUser({ isEmailVerified: false });
const neverLoggedIn = createMockUser({ lastLoginAt: null });

Part 5: Coverage and Review

Coverage tools tell you which lines were executed. They don't tell you whether the tests were any good. Use AI for both: generating tests toward coverage gaps, and reviewing what was generated.

Filling Coverage Gaps

This is more useful than chasing 100% coverage blindly. You're targeting specific gaps with tests that have a reason to exist — not padding for the metric.

Asking AI to Review Its Own Tests

AI-generated tests can have blind spots — testing implementation details, writing assertions that always pass, or missing the actual behavior under test. Build review into the workflow:

A good AI response to this prompt will find at least one real issue in most generated test suites. Common findings: an assertion like expect(result).toBeDefined() that passes even when result is wrong; a test that mocks so much there's nothing real being tested; a missing assertion on the return value shape.

Part 6: Prompt Patterns That Work

The quality of AI-generated tests depends heavily on the prompt. Here are the patterns that consistently produce better output.

Specify the Framework Explicitly

Don't assume AI knows your stack. Always name the framework and version if it matters:

// Good
"Write tests using Vitest and Testing Library."
"Write tests using Jest with ts-jest. We're on Jest 29."
"Write integration tests using Supertest. The app is Express 4."

// Too vague
"Write tests for this function."

Describe What Counts as Success

"Test this function" produces generic tests. "Test that it returns X when Y, throws Z when W, and calls Q with R" produces useful ones:

Use "Given / When / Then" Language

Structured descriptions map cleanly to test cases:

Ask for a Test Plan Before the Tests

For complex areas, generate a list of what should be tested first, confirm it looks right, then ask for the code:

Review the list. Add anything domain-specific the AI missed. Delete anything irrelevant. Then: "Now write the tests for items 1, 2, 3, 5, 7, and 9."