CC-301h · Module 1

Test Generation Principles

4 min read

Claude generates tests that pass. That is the easy part and the dangerous part. A test that passes is not necessarily a test that validates behavior. Claude can produce fifty tests that all pass and none of them catch the bug you are worried about. The discipline is not in generating tests — it is in specifying what the tests should validate.

The effective prompt is not "Write tests for this function." The effective prompt is "Write tests for this function that cover: (1) the happy path with valid input, (2) edge cases — empty input, null, maximum values, (3) error conditions — what should this function do when the database is down? (4) boundary conditions — what happens at exactly the rate limit?" This specificity tells Claude what behaviors to validate, not just what code to exercise.

Do This

  • Specify the behaviors to test: happy path, edge cases, error conditions
  • Ask Claude to test the contract, not the implementation
  • Review generated tests for assertion quality — do they assert the right things?
  • Use generated tests as a starting point and add domain-specific assertions

Avoid This

  • Say "Write tests for this file" and accept whatever Claude produces
  • Measure test quality by quantity — 50 shallow tests are worse than 10 deep ones
  • Accept tests that only assert "does not throw" without validating output
  • Skip reviewing generated tests — Claude sometimes tests implementation details