Testing Patterns

You just finished implementing a payment processing service. It works in your manual testing, but you have no automated tests. Writing tests for 15 functions across payment creation, validation, refunds, and webhook handling feels like it will take longer than writing the service itself. So you ship it without tests, promising yourself you will add them later. Two weeks later, a refactoring breaks the refund logic and nobody catches it until a customer reports it.

AI is remarkably good at writing tests. It can analyze your code, identify the important paths and edge cases, and generate a comprehensive test suite in minutes. The key is knowing how to prompt for tests that actually catch bugs, not tests that just achieve coverage numbers.

What You’ll Walk Away With

• A workflow for generating comprehensive test suites from existing code
• The test-driven development pattern with AI (write tests first, then implementation)
• Techniques for adding tests to untested legacy code
• Copy-paste prompts that produce high-quality, maintainable tests

The Test-First Pattern (TDD with AI)

The most powerful testing pattern with AI: write the tests first, then let Agent write the implementation and iterate until the tests pass.

Tip

Copy-paste prompt for test-driven development:

I need a function that converts Markdown to HTML.

Step 1: Write tests first in src/utils/__tests__/markdown-to-html.test.ts

Test cases to cover:
- Basic formatting: bold, italic, links, headings (h1-h6)
- Code blocks: inline code and fenced code blocks with language tags
- Lists: ordered and unordered, including nested lists
- Edge cases: empty string, null input, malformed markdown, HTML entities
- Security: XSS prevention (script tags should be escaped)

Step 2: Implement the function in src/utils/markdown-to-html.ts

Step 3: Run the tests. Fix any failures. Repeat until all tests pass.

Use the test patterns from @src/utils/__tests__/date-utils.test.ts.

Why this works: the AI writes tests based on your specification of expected behavior. Then it writes an implementation that passes those tests. If a test fails, the implementation is wrong (not the test), so the AI fixes the implementation. This prevents the common problem of AI “fixing” tests to match broken code.

Generating Tests for Existing Code

Comprehensive Test Suite Generation

Tip

Copy-paste prompt for test generation:

Write a comprehensive test suite for @src/services/payment-service.ts.

Requirements:
- Test file: src/services/__tests__/payment-service.test.ts
- Framework: Vitest
- Mock all external dependencies (Stripe SDK, database, email service)
- Use factory functions for test data

For each public function, test:
1. Happy path with valid inputs
2. Validation errors (invalid inputs, missing required fields)
3. External service failures (Stripe returns error, database timeout)
4. Edge cases (zero amounts, currency mismatches, duplicate payments)
5. Authorization errors (user does not have permission)

Name tests descriptively: "should [behavior] when [condition]"

Follow the testing patterns in @src/services/__tests__/user-service.test.ts.
Run the tests after writing them.

Adding Tests to Legacy Code

For untested code where you are not sure what it does:

Tip

Copy-paste prompt for characterization tests:

@src/services/legacy-pricing-engine.ts has no tests and the business logic is complex.

Write characterization tests that document the current behavior:
1. Read the code and identify every public function
2. For each function, determine what it does based on the implementation
3. Write tests that assert the current behavior (even if the behavior seems wrong)
4. Mark any tests where the behavior seems like a potential bug with a TODO comment

These tests are not validating correctness -- they are capturing existing behavior so we can refactor safely.

Test file: src/services/__tests__/legacy-pricing-engine.test.ts

Characterization tests are essential before refactoring legacy code. They tell you when your refactoring changes behavior, even if the original behavior was not documented.

Building on an Existing Test Suite

One of the most practical patterns: incrementally expand test coverage by analyzing what is not tested.

Tip

Copy-paste prompt for coverage expansion:

Run `npm test -- --coverage` and look at the coverage report for @src/services/order-service.ts.

Identify the uncovered lines and branches. Then write additional tests that cover:
1. The uncovered error handling paths
2. The untested edge cases
3. Any branch conditions that are only partially covered

Add the new tests to the existing test file @src/services/__tests__/order-service.test.ts.
Follow the existing test style and organization.

Run the tests to make sure the new tests pass and overall coverage increased.

Using Failing Tests from Production Bugs

When you encounter a production bug, the first step should be writing a test that reproduces it:

We discovered a bug: orders with decimal quantities (e.g., 2.5 units)
cause the total calculation to return NaN.

Before fixing the bug:
1. Write a failing test that demonstrates the exact bug
2. The test should pass valid decimal quantities and assert the correct total
3. Run the test to confirm it fails with the current code

Then fix the bug and confirm the test passes.

This ensures the fix actually addresses the issue and prevents regression.

Test Data Factory Pattern

Instead of writing inline test objects in every test, create factory functions:

Tip

Copy-paste prompt for test factories:

Create a test data factory file at src/test-utils/factories.ts.

Analyze the types in @src/types/ and create factory functions for:
- createUser(overrides?) - returns a valid User object with sensible defaults
- createOrder(overrides?) - returns a valid Order with linked user
- createPayment(overrides?) - returns a valid Payment with linked order

Each factory should:
- Return complete, valid objects with default values
- Accept partial overrides to customize specific fields
- Use incrementing IDs to avoid collisions
- Generate realistic but predictable test data

Follow this pattern:
```typescript
export function createUser(overrides?: Partial<User>): User {
  return {
    id: `user-${nextId()}`,
    email: `test-${nextId()}@example.com`,
    firstName: 'Test',
    lastName: 'User',
    ...overrides,
  }
}
```

When This Breaks

AI writes tests that just assert the implementation. If a test calls a function and asserts that the return value is whatever the function returns, it is testing nothing. Specify the expected behavior explicitly in your prompt: “should return 42 when given inputs X and Y.”

Tests pass but do not catch real bugs. The tests are too focused on happy paths. Always explicitly request error path testing, edge case testing, and boundary condition testing.

AI “fixes” the test instead of the code. Explicitly state: “The test represents the correct behavior. The implementation is wrong. Fix the implementation.”

Generated tests are flaky. Tests that depend on timing, random values, or external state are unreliable. Add to your testing rule: “Never use real timers, random values, or network calls in unit tests. Mock everything.”

Test file becomes too large. Split tests by domain (auth tests, profile tests, payment tests) rather than having one monolithic test file per service.

What’s Next

• Debugging Workflows — Tests are the foundation of effective debugging
• Refactoring Strategies — Tests enable safe refactoring
• Review Workflows — Reviewing AI-generated tests alongside code