Test Case Generation

What You’ll Learn

• How to prompt Claude to generate unit tests that cover not just happy paths but edge cases and error conditions
• Techniques for generating integration tests, test data fixtures, and property-based test cases
• How to use Claude to audit your existing test suite for coverage gaps

The Use Case

Writing tests is one of the most high-value but time-consuming parts of software development. Most developers know they should write more tests — the bottleneck isn’t intention, it’s time. Thinking through every edge case, writing the test harness, generating realistic test data, and maintaining tests as code changes all take significant effort. Claude can dramatically accelerate this work.

The key insight is that test generation is something Claude does particularly well because it requires systematic enumeration of cases — which Claude is better at than humans in flow state. While you might write tests for the obvious inputs and call it done, Claude will methodically think through: what if the input is empty? What if it’s at the boundary of a constraint? What if a dependency returns an unexpected type? What if two valid inputs interact in a surprising way?

This applies across test types. For unit tests, Claude writes focused assertions around a single function. For integration tests, Claude can generate full request/response cycles against your API. For test data, Claude creates realistic fixtures with the right relationships between entities. For property-based tests, Claude can describe the invariants your code should always satisfy.

Step-by-Step Guide

Step 1: Provide the code under test and your test framework

Always start by specifying:

• What testing library/framework you use (Jest, pytest, Go testing, JUnit, RSpec, etc.)
• Any mocking library (Jest mocks, unittest.mock, sinon, etc.)
• The code you want to test (paste the full function or class)

Claude needs to know the framework to generate syntactically correct tests and use the right assertion APIs.

Step 2: Ask for systematic coverage across categories

Don’t just ask for “some tests.” Ask Claude to cover specific categories:

• Happy path — standard valid inputs with correct expected outputs
• Boundary conditions — values at the edges of valid ranges (0, -1, max int, empty string, single element, etc.)
• Invalid inputs — null/undefined, wrong types, out-of-range values
• Error conditions — what happens when dependencies fail, network is unavailable, etc.
• Concurrency or timing — if applicable

Structure your prompt: “Write unit tests covering: (1) normal usage, (2) boundary values, (3) invalid inputs that should throw errors, and (4) cases where the external dependency returns an error.”

Step 3: Ask for realistic test data

Placeholder test data (name: "test", id: 1) produces brittle tests that may not catch real-world failures. Ask Claude for realistic-looking data:

“Use realistic-looking test data — real-looking names, valid email formats, realistic dollar amounts, actual ISO date strings.”

For complex entity graphs with relationships, describe the relationships and ask Claude to generate fixture data that satisfies all foreign key constraints and business rules.

Step 4: Request test descriptions that document intent

Good test names and descriptions are documentation. Ask Claude to write test names that describe the scenario and the expected outcome, not just the function being tested:

• Weak: test_process_payment()
• Strong: test_process_payment_raises_InsufficientFunds_when_balance_is_below_amount()

Add to your prompt: “Name each test to describe the scenario being tested and the expected outcome. Follow the pattern: test_[function]_[scenario]_[expected].”

Step 5: Audit existing tests for gaps

Paste your existing test file and the code it tests, then ask:

“Review these existing tests against the code. What cases are not currently covered? List the missing test scenarios, then write the missing tests.”

This is one of the most efficient uses of Claude for testing — it reads both the production code and the test code and identifies the delta.

Prompt Template

Framework: [pytest / Jest / Go testing / JUnit / etc.]
Mocking library: [unittest.mock / jest.fn() / sinon / etc. — or "none needed"]

Here is the function/class I want to test:

[PASTE CODE UNDER TEST]

Please write comprehensive tests covering:
1. Normal usage (happy path) with typical valid inputs
2. Boundary conditions (empty inputs, single items, max values, min values)
3. Invalid inputs that should raise errors or return error states
4. [Any domain-specific cases, e.g., "cases where the database call fails"]
5. [Any concurrency or async behavior if applicable]

Requirements:
- Use realistic test data, not placeholders like "test" or "1234"
- Name each test to describe the scenario and expected outcome
- Add a brief comment above each test group explaining what's being tested
- Mock any external dependencies ([list them, e.g., "the database call", "the HTTP request"])

Tips & Best Practices

1. One test per behavior, not one test per function — Ask Claude to write one test per distinct behavior rather than one big test per function. “Each test should verify exactly one thing. If a test has more than one logical assertion group, split it.” This makes test failures pinpoint the exact problem.

2. Ask for both positive and negative assertions — Many test suites only verify that things work correctly. Ask Claude to also write tests for invalid states: “Include tests that verify the function raises the correct exception type (not just any exception) when given invalid input.”

3. Generate property-based test descriptions — For functions with mathematical properties (commutativity, idempotency, monotonicity), ask Claude to describe invariants: “What properties should always hold for this function, regardless of input? Describe them, and write property-based tests if the framework supports it (e.g., Hypothesis for Python, fast-check for JavaScript).”

4. Ask for test data factories, not hardcoded fixtures — For entity-heavy tests, ask Claude to generate factory functions rather than hardcoded objects. “Instead of hardcoded test objects, write a make_order() factory function with sensible defaults and keyword overrides, so each test can customize only the fields relevant to it.”

5. Have Claude write a test plan before writing tests — For complex code, ask for a test plan first: “Before writing any code, list all the scenarios you plan to test and why. I’ll review the plan and then you can write the tests.” This surfaces coverage strategy decisions before you’re committed to specific test implementations.

Try It Yourself

Pick a pure function from your codebase — one with no side effects, no external dependencies, just input in and output out. Paste it into Claude with this prompt:

“Write comprehensive pytest tests for this function. Cover: normal usage with at least 3 different valid inputs, boundary conditions (empty, None, single-element lists, very large values — whatever is relevant), and at least 3 invalid input cases that should raise exceptions. Use realistic test data and name each test to describe the scenario.”

Run the generated tests. See how many edge cases Claude thought to cover that you wouldn’t have written yourself.