Claude Architect · Lesson

Test Generation & Standards

Document fixtures and standards to improve generated tests.

Why Generated Tests Drift

Ask Claude Code to "write tests for this module" with no guidance and you get tests that run but don't match your house style: wrong framework helpers, invented fixtures, assertions that mirror the implementation instead of the contract.

The fix is not a better one-off prompt. It is persistent, shared standards the model reads on every run. This lesson shows how to document fixtures and conventions so generated tests come out idiomatic, deterministic, and reviewable, in interactive sessions and in CI alike.

Standards Live in Project-Scope CLAUDE.md

Test conventions belong in project-level config so every contributor and every CI runner sees them. Put them in ./CLAUDE.md or .claude/CLAUDE.md, which is shared via VCS.

Do NOT rely on user-level ~/.claude/CLAUDE.md: it is personal, NOT shared through version control, so new teammates and your pipeline simply won't have it. Anything your test generation depends on must live in project scope.

# ./CLAUDE.md  (committed -> every dev + CI sees it)

## Testing standards
- Framework: pytest; one test file per module as tests/test_<module>.py
- Name tests test_<behavior>_<condition>_<expected>
- Assert on the public contract, never on private internals
- No network or real time in unit tests; use the provided fixtures

All lessons in this course

← Back to Claude Architect