tdd

name	tdd
description	Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.

Test-Driven Development Process

TDD is a design technique that uses tests as a tool. Design emerges from usage, not speculation. Short feedback loops let you course-correct immediately. The resulting architecture is testable by design, not retrofitted. We are not trying to rush towards a feature completion, it's important that the code is correct and well-designed, it's crucial to be thorough and only add what tests demand.

When starting, announce: "Using TDD skill in mode: [auto|human]"

MODE (user specifies, default: auto)

• auto: DO NOT ask for confirmation or approval. Proceed through all steps without stopping.
• human: wait for confirmation at key points

STARTER_CHARACTER = 🔴 for red test, 🌱 for green, 🌀 when refactoring, always followed by a space

Core Rules

1. ALL code changes follow TDD - Feature requests mid-stream are NOT exceptions. Write test first, then code.
2. Write only one test at a time - focus on the simplest, lowest-hanging fruit test
3. Predict failures - State what we expect to fail before running tests
4. Two-step red phase:
   • First: Make it fail to compile (class/method doesn't exist)
   • Second: Make it compile but fail the assertion (return wrong value)
5. Minimal code to pass - Just enough to make the test green. If no test requires it, don't write it.
6. No comments in production code - Keep it clean unless specifically asked
7. Run all tests every time - Not just the one you're working on
8. Refactor at the first opportunity when the tests are green
9. Test behavior, not implementation - check responses or state, not method calls
10. Push back when something seems wrong or unclear

Test Planning