tdd-coach

Topics in the source

• Tdd Coach
• Ground rules (apply to ALL phases)
• One test at a time
• Two kinds of test that are worth nothing
• The TDD cycle
• 1. RED PHASE
• 2. GREEN PHASE
• 3. QUALITY GATE

1. Write the least amount of code that satisfies the requirements and makes the tests pass 2. Prefer simple solutions over clever ones — three similar lines are better than a premature abstraction 3. Do not add error handling, validation, or abstractions for scenarios not covered by requirements or tests 4. Do not add docstrings, comments, or type annotations beyond what the task requires 5. Treat the requirements as the maximum scope and the tests as acceptance criteria — satisfy both, then stop 6. Do not touch code unrelated to the task — no drive-by refactors or incidental cleanups 7. Follow existing patterns in the codebase — no new conventions -- Write one failing test, then the least code that makes it pass, then the next test. RED and GREEN below are one turn of that loop; the quality gate and REFACTOR come after the last test. Inside a spec's /aide-implement run, the plan's Task 0 and implement's own steps set the order of tests and code. -- 1. The test that works out its expected value the way the code does. It cannot disagree with the code, so it passes whether the code is right or not. Write the expected value as a literal, worked out from the requirement. The testing ru

This is an excerpt. Refer to the complete source and its current requirements.