Lesson Content

Behavior-focused test generation.

The default Claude Code test generation output tests implementation details – what internal functions are called, what exact return structure is produced. These tests break on refactoring even when behavior is preserved. Behavior-focused tests survive refactoring because they test inputs and expected outputs.

Request pattern for behavior-focused tests:

Write tests for `processOrder()` that:
– Test the function's observable behavior (inputs and expected outputs)
– Do not assert on internal implementation details
– Cover these cases: valid order, empty cart, negative quantity, unavailable item, payment failure
– Use [team's test framework] and [team's assertion style from CLAUDE.md]

The explicit case list in the request is the key element – it forces test coverage of the edge cases you specify rather than the happy path Claude defaults to.

The edge-case specification technique.

Before asking for test generation, ask Claude to identify edge cases:

1. "What are the edge cases and boundary conditions for this function?"
2. Review Claude's list – add any your domain knowledge surfaces that Claude missed
3. Pass the complete list as the coverage specification for test generation

This two-step pattern produces more comprehensive tests than one-step generation because it forces explicit edge case identification before writing the tests.

Scoped code review.

The most useful Claude Code review requests are specific:

• Security review: "Review src/auth/ for authentication vulnerabilities – specifically session management, token validation, and input sanitization"
• Performance review: "Review this database query and the data it operates on for N+1 query patterns"
• Style review: "Review this PR diff for adherence to the conventions in CLAUDE.md"
• Logic review: "Review this function for unhandled edge cases – specifically null inputs, empty collections, and integer overflow"

Each scoped review produces findings in a specific domain. Generic "review this code" produces a surface-level observation that requires more follow-up.

The pre-commit review habit.

A two-minute pre-commit Claude Code review habit:

1. git diff --staged to see what you are about to commit
2. Share the diff with Claude: "Review this diff for obvious issues before I commit"
3. Address any findings, then commit

Not every pre-commit review finds something. But the ones that do – catching a missing error handler, an unvalidated input, an off-by-one – are worth the two minutes every time.