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.

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Limitations

• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.