Claude for Writing Unit Tests

A team I heard about once shipped a feature with 95% test coverage that caught exactly zero real bugs over the following three months. Every test passed, every time, including on the build that shipped a genuine regression. The problem wasn't the coverage percentage — it was that every test exercised the happy path, and that's the most common failure mode in claude unit test prompts too.

What is a Good Unit Test Prompt?

A good prompt for generating tests explicitly asks for edge cases, not just confirmation that the function works as intended on clean input. Left unprompted, Claude — like most developers under time pressure — will generate tests that mirror the function's obvious intended use and skip the inputs that actually break things.

Why It Matters

Tests that only cover the happy path give false confidence. They pass every CI run, they look good in a coverage report, and they do nothing to catch the null input, the empty array, or the concurrent write that causes your actual production incident six months later.

Generating Tests That Cover Edge Cases

Here's the function: [paste function]

Write unit tests using [testing framework, e.g. pytest/Jest] covering:
1. The primary intended use case
2. Boundary values (empty input, zero, negative numbers, max int
   if relevant)
3. Invalid input types and how the function should handle them
4. Any edge case implied by the function's own error handling

For each test, name it descriptively so the test name alone explains
what's being verified.

What this does: Numbering the categories explicitly — especially "boundary values" and "invalid input types" — is what pulls Claude away from generating five variations of the same happy-path test and toward the inputs that actually reveal bugs.

⚡ Pro tip: After generating tests, ask "which of these tests would fail if I accidentally introduced an off-by-one error in the boundary condition?" If none of them would, you're missing the test that actually matters most.

Testing With Mocks and Dependencies

This function calls [external dependency, e.g. a database or API]:
[paste function]. Write tests that mock this dependency, including
a test for the case where the dependency returns an error or times
out. Use [mocking library] following this existing pattern in our
codebase: [paste an example mock from an existing test]

⚠️ Common mistake: Not testing what happens when a dependency fails. Most production incidents involving external services aren't "the API is down" — they're "the API returned something unexpected and our code didn't handle it," which only a deliberately-written failure-case test catches.

Writing Tests for Legacy Code With No Existing Coverage

This function has no existing tests and I need to refactor it safely:
[paste function]. Write characterization tests that document its
current actual behavior — including any behavior that looks like a
bug — so I have a safety net before I change anything. Flag any
behavior you think might be an unintentional bug rather than
"fixing" it in the test.

What this does: Characterization tests capture what the code actually does today, bugs and all, which is the correct first move before refactoring legacy code — you want a safety net, not a test suite that encodes the fix before you've decided to make it.

Scenario: QA engineer inheriting an untested payment module A QA engineer at a fintech startup inherited a payment calculation module with zero test coverage and used the characterization-test prompt to build a safety net before a planned refactor, and one of the "possible bug" flags Claude raised turned out to be a real rounding error that had been silently present in production for months.

Scenario: Backend developer adding tests to meet a new CI requirement A backend developer facing a new company-wide coverage requirement used the edge-case prompt structure across a batch of older functions, specifically asking for boundary and invalid-input tests to avoid just padding coverage numbers with redundant happy-path tests.

Scenario: Startup CTO test-driving a new feature A startup CTO practicing test-driven development used Claude to generate tests from a function's spec before the function itself existed, then wrote the implementation to satisfy tests that already covered edge cases she might not have thought of first.

Common Mistakes

⚠️ Common mistake: Accepting generated tests without running them against the actual function first. Occasionally a generated test encodes an assumption about behavior that doesn't match what the function actually does — always run the suite and read any failure carefully before assuming the test itself is wrong.

⚠️ Common mistake: Treating high coverage percentage as the goal instead of a proxy for it. A codebase with 60% coverage on the right edge cases is safer than one with 95% coverage that only exercises the happy path.

Conclusion

The fix for claude unit test prompts is the same fix that applies to human-written tests: ask explicitly for edge cases, failure modes, and boundary conditions, because nobody — human or AI — generates them by default under time pressure. Once you've got a prompt template that reliably produces this kind of coverage, save it in PromptABCD so every new function starts with a real safety net, not just a passing green checkmark.