My testing strategy with Claude Code (what actually catches bugs)

Claude Code will write tests for anything you ask it to. The problem: unconstrained, it writes tests that confirm what the code does rather than tests that catch when the code breaks. Here's the testing strategy that's worked for me. Test behavior, not implementation The prompt matters: ❌ "Write tests for this function" ✅ "Write tests that verify the behavior of this function from a caller's perspective. Don't test internal implementation details." When Claude tests implementation details, every refactor breaks your tests even when nothing actually broke. Lead with edge cases Claude's default is happy path first. Flip this: Write tests for [function]. Start with edge cases: - Empty/null inputs - Boundary values (0, -1, max int) - Invalid types - Concurrent calls (if applicable) Then add the happy path. Edge cases are where real bugs live. If Claude writes them first, they get proper attention. One assertion per test Claude packs multiple assertions into single tests unless you stop it.