tdd-workflow

# TDD Workflow > Write tests first, code second. --- ## 1. The TDD Cycle ``` 🔴 RED → Write failing test ↓ 🟢 GREEN → Write minimal code to pass ↓ 🔵 REFACTOR → Improve code quality ↓ Repeat... ``` --- ## 2. The Three Laws of TDD 1. Write production code only to make a failing test pass 2. Write only enough test to demonstrate failure 3. Write only enough code to make the test pass --- ## 3. RED Phase Principles ### What to Write | Focus | Example | |-------|---------| | Behavior | "should add two numbers" | | Edge cases | "should handle empty input" | | Error states | "should throw for invalid data" | ### RED Phase Rules - Test must fail first - Test name describes expected behavior - One assertion per test (ideally) --- ## 4. GREEN Phase Principles ### Minimum Code | Principle | Meaning | |-----------|---------| | **YAGNI** | You Aren't Gonna Need It | | **Simplest thing** | Write the minimum to pass | | **No optimization** | Just make it work | ### GREEN Phase Rules - Don't write unneeded code - Don't optimize yet - Pass the test, nothing more --- ## 5. REFACTOR Phase Principles ### What to Improve | Area | Action | |------|--------| | Duplication | Extract common code | | Naming | Make intent clear | | Structure | Improve organization | | Complexity | Simplify logic | ### REFACTOR Rules - All tests must stay green - Small incremental changes - Commit after each refactor --- ## 6. AAA Pattern Every test follows: | Step | Purpose | |------|---------| | **Arrange** | Set up test data | | **Act** | Execute code under test | | **Assert** | Verify expected outcome | --- ## 7. When to Use TDD | Scenario | TDD Value | |----------|-----------| | New feature | High | | Bug fix | High (write test first) | | Complex logic | High | | Exploratory | Low (spike, then TDD) | | UI layout | Low | --- ## 8. Test Prioritization | Priority | Test Type | |----------|-----------| | 1 | Happy path | | 2 | Error cases | | 3 | Edge cases | | 4 | Performance | --- ## 9. Anti-Patterns | ❌ Don't | ✅ Do | |----------|-------| | Skip the RED phase | Watch test fail first | | Write tests after | Write tests before | | Over-engineer initial | Keep it simple | | Multiple asserts | One behavior per test | | Test implementation | Test behavior | --- ## 10. AI-Augmented TDD ### Multi-Agent Pattern | Agent | Role | |-------|------| | Agent A | Write failing tests (RED) | | Agent B | Implement to pass (GREEN) | | Agent C | Optimize (REFACTOR) | --- > **Remember:** The test is the specification. If you can't write a test, you don't understand the requirement. ## Technique Map - **Role definition** - Clarifies operating scope and prevents ambiguous execution. - **Context enrichment** - Captures required inputs before actions. - **Output structuring** - Standardizes deliverables for consistent reuse. - **Step-by-step workflow** - Reduces errors by making execution order explicit. - **Edge-case handling** - Documents safe fallbacks when assumptions fail. ## Technique Notes These techniques improve reliability by making intent, inputs, outputs, and fallback paths explicit. Keep this section concise and additive so existing domain guidance remains primary. ## Prompt Architect Overlay ### Role Definition You are the prompt-architect-enhanced specialist for tdd-workflow, responsible for deterministic execution of this skill's guidance while preserving existing workflow and constraints. ### Input Contract - Required: clear user intent and relevant context for this skill. - Preferred: repository/project constraints, existing artifacts, and success criteria. - If context is missing, ask focused questions before proceeding. ### Output Contract - Provide structured, actionable outputs aligned to this skill's existing format. - Include assumptions and next steps when appropriate. - Preserve compatibility with existing sections and related skills. ### Edge Cases & Fallbacks - If prerequisites are missing, provide a minimal safe path and request missing inputs. - If scope is ambiguous, narrow to the highest-confidence sub-task. - If a requested action conflicts with existing constraints, explain and offer compliant alternatives.