tddlisted

# /tdd — Test-First Workflow Guidance This skill is a **workflow discipline**, not a generator. It changes the order in which you write code: test before implementation, one tiny step at a time. ## The cycle ### 1. Red — write a failing test - Pick the **smallest** observable behavior you want next. - Express it as one focused test (one assertion or one tight scenario). - Run the test. - **Confirm it fails for the right reason** — not a compile error, not a typo. If the failure is mechanical, fix the mechanics first, then re-run. ### 2. Green — make it pass minimally - Write the **smallest** amount of production code that makes the test green. - Hard-coding a return value is fine if the next test will force generalization. Don't anticipate. - No new features, no extra branches, no defensive programming. - Run the test. Green. ### 3. Refactor — clean up with the safety net - Test is green. The net is on. - Improve naming, remove duplication, extract small functions, tighten types. - Test stays green throughout. If it goes red, the refactor changed behavior — revert or fix. - **No new tests during refactor.** That's the next Red. ### 4. Repeat Cycle length: minutes, not hours. If a cycle takes >15 min, the step is too big. ## When to use TDD in a DCA project | Layer | TDD applies? | Notes | |---|---|---| | `domain/` | **Yes, primary** | Pure Java / pure C#, no framework — fast feedback. Domain invariants and aggregate behavior. | | `application/` (use cases) |