tddlisted

# Test-Driven Development TDD uses tests as a design tool. The test suite is a byproduct — the real output is clean design that emerges from writing tests first. Code is only written to satisfy a failing test. --- ## Before Starting Gather context before writing anything. A wrong assumption means wrong tests. 1. **Find existing tests.** Match their framework and style exactly. Only ask about tooling if nothing exists yet. 2. **Read code this task integrates with.** Discover interfaces rather than inventing them. 3. **Clarify behavior if vague.** If the request is ambiguous ("add authentication"), ask for a concrete scenario: "What should happen when a user logs in with the wrong password?" One focused question beats a checklist. --- ## The Cycle: Red -> Green -> Refactor Every unit of work follows three steps. Never skip the third. ### Red — Write a failing test - Pick the next smallest piece of behavior - Write a test that will pass once that behavior exists - Assert what you actually expect, not a placeholder. If you don't know the exact value (e.g., a specific error message string), assert the contract you care about (e.g., "raises `ValueError`") rather than guess. Tweaking the assertion later to match whatever the implementation happens to emit is test-after, not test-first — see Pitfalls. - Run it — confirm it **fails for the right reason** (not a syntax error or import failure) - If writing the test is hard, that's a design signal: the inte