# TDD Workshop - Complete Plan

**Title:** Test-Driven Development Workshop: From Theory to Practice  
**Duration:** 2 hours (120 minutes)  
**Format:** In-person, hands-on  
**Target Audience:** Developers familiar with TDD concepts but lacking hands-on practice  
**Language:** Dart  
**Primary Goal:** Build muscle memory for the RED-GREEN-REFACTOR cycle through deliberate practice

---

## Pre-Workshop Preparation

### 1 Week Before
- [ ] Confirm participant count and send calendar invite
- [ ] Share repository link with setup instructions (SETUP_GUIDE.md)
- [ ] Ask participants to complete setup and verify `dart pub get` + `dart test` work
- [ ] Prepare a backup laptop with environment pre-configured
- [ ] Review this plan and the FACILITATOR_GUIDE.md

### 1 Day Before
- [ ] Practice FizzBuzz live demo (use DEMO_SCRIPT.md)
- [ ] Review password_validator and shopping_cart solution files
- [ ] Test all katas on your machine (`dart test` in each directory)
- [ ] Print this workshop plan as backup reference
- [ ] Prepare any slides (optional - just 3-4 slides max)

### Morning of Workshop
- [ ] Arrive 15 minutes early to set up room
- [ ] Test projector / screen sharing
- [ ] Open all relevant files in your editor:
  - fizzbuzz/lib/fizzbuzz.dart
  - fizzbuzz/test/fizzbuzz_test.dart
  - fizzbuzz/DEMO_SCRIPT.md
- [ ] Have terminal ready with `dart test` command
- [ ] Write schedule on whiteboard for participant reference
- [ ] Open git log for FizzBuzz: `git log --oneline`

---

## Materials Checklist

### Digital Materials
- [ ] Workshop repository cloned and working
- [ ] FizzBuzz kata prepared for live demo
- [ ] TDD_REFERENCE_CARD.md ready to share
- [ ] Link to tdd-katas repo bookmarked (for post-workshop)
- [ ] Backup: Repository on USB drive (if network fails)

### Physical Materials
- [ ] Whiteboard and markers (for schedule and collecting insights)
- [ ] Sticky notes (for participants to write questions)
- [ ] This printed workshop plan
- [ ] FACILITATOR_GUIDE.md printed as backup

---

## Detailed Schedule

| Start | Duration | Segment | Format |
|-------|----------|---------|--------|
| 0:00 | 10 min | Welcome & Setup Check | Facilitator-led |
| 0:10 | 15 min | Live Demo: FizzBuzz TDD | Live-coding |
| 0:25 | 5 min | Exercise Introduction | Facilitator-led |
| 0:30 | 45 min | Hands-on Practice (Part 1) | Solo/pairs coding |
| 1:15 | 15 min | Mid-Point Check-in | Group discussion |
| 1:30 | 30 min | Hands-on Practice (Part 2) | Solo/pairs coding |
| 2:00 | 10 min | Show & Tell | 2-3 volunteers |
| 2:10 | 10 min | Retrospective Discussion | Facilitated |

---

## Segment-by-Segment Guide

### Segment 1: Welcome & Setup (0:00-0:10) — 10 minutes

**Objectives:**
- Ensure everyone can run tests
- Set expectations
- Create psychological safety

**Script:**
```
Welcome! Today we're building TDD muscle memory through practice.

Quick poll:
- Written unit tests before? [Most hands should go up]
- Tried writing tests BEFORE code? [Some hands]
- Do it regularly, every day? [Few/no hands]

That's totally normal. Today is about practice, not theory.

Setup check - everyone run:
  cd tdd-workshop/password_validator
  dart pub get
  dart test

You should see "All tests skipped" or passing tests. Raise your hand if you see errors.

The rhythm we'll practice:
1. RED - Write a test, watch it fail
2. GREEN - Write minimal code to pass
3. REFACTOR - Clean up
4. REPEAT

Let's see this in action.
```

**Actions:**
- [ ] Display repo URL on screen
- [ ] Walk around to help with setup issues
- [ ] Ensure everyone has green/skipped tests

**What Success Looks Like:**
- Everyone has tests running
- No one is stuck on setup
- Energy is positive and relaxed

---

### Segment 2: Live Demo - FizzBuzz (0:10-0:25) — 15 minutes

**Objectives:**
- Demonstrate RED-GREEN-REFACTOR in real-time
- Show what "minimal implementation" means
- Model thinking process out loud

**Preparation:**
- Open fizzbuzz directory
- Have DEMO_SCRIPT.md open on second screen
- Terminal ready to run `dart test`

**Follow the detailed script in `fizzbuzz/DEMO_SCRIPT.md`**

**Key Talking Points:**
- "Notice I run tests every 30 seconds"
- "This looks silly but it passes"
- "The tests are documenting the rules"
- "I didn't design this upfront - it emerged"
- "Order matters! (15 before 3 and 5)"

**What Success Looks Like:**
- Completed 5 RED-GREEN cycles in 15 minutes
- Participants see the rhythm clearly
- At least one "aha!" moment visible (nodding, note-taking)

**Time Check:** Should finish by 0:25

---

### Segment 3: Exercise Introduction (0:25-0:30) — 5 minutes

**Objectives:**
- Explain the two kata choices
- Clarify workflow
- Get people started

**Script:**
```
Now it's your turn. Two katas to choose from:

PASSWORD VALIDATOR:
- Rules-based validation (length, uppercase, digits...)
- Step 6 has the interesting refactoring challenge
- Good for practicing: extracting patterns, Open-Closed Principle

SHOPPING CART:
- Stateful domain object (add, remove, calculate)
- You'll discover when to use Map vs List
- Good for practicing: Value Objects, data structure decisions

Both are good. Pick what sounds interesting.

Workflow:
1. Open the test file
2. Uncomment ONE test group
3. Run dart test - see it RED
4. Write code to make it GREEN
5. Refactor if needed
6. Next test

Pairing optional - if you pair, try "ping-pong":
- Person A writes test
- Person B makes it pass
- Switch roles

Questions? Good. Choose your kata and start with Step 1!
```

**Actions:**
- [ ] Show README files on screen briefly
- [ ] Start 45-minute timer
- [ ] Let people move to pair up if desired

**What Success Looks Like:**
- Everyone has chosen a kata
- Files are open
- First test is being uncommented

---

### Segment 4: Hands-on Practice Part 1 (0:30-1:15) — 45 minutes

**Objectives:**
- Build RED-GREEN-REFACTOR muscle memory
- Experience how tests drive design
- Encounter and resolve "stuck" moments

**Your Role:** Circulate, observe, nudge with questions (don't give solutions)

**Good Signs:**
- Tests running frequently
- Seeing RED before touching lib/
- Small commits or at least incremental changes
- Discussing design (if pairing)

**Interventions (Use these phrases):**

| Situation | What to Say |
|-----------|-------------|
| Writing code without test | "Have you run the test yet? What did it say?" |
| Multiple tests at once | "Let's focus on making just ONE test pass first" |
| Overthinking | "What's the simplest thing that could work?" |
| Not refactoring | "See any duplication? What could you extract?" |
| Stuck on data structure | "What makes 'find by name' really easy?" (Shopping Cart) |
| Hardcoding too long | "Try another test with different input. What happens?" |

**Guiding Questions:**
- "What's the next simplest test?"
- "Can you pass with even less code?"
- "Now that it's green, what needs cleaning up?"
- "How would this scale to 20 rules?" (Password)
- "Why List vs Map here?" (Shopping Cart)

**Time Checks:**
- **At 15 min (0:45):** Most should be on Step 2-3
- **At 30 min (1:00):** Most should be on Step 3-4
- **At 40 min (1:10):** Some on Step 5-6, some still on 3-4 (both fine)

**What Success Looks Like:**
- Steady typing and test running
- Some "aha!" moments (facial expressions, discussions)
- A few stuck moments that resolve with nudging
- Energy remains positive

---

### Segment 5: Mid-Point Check-in (1:15-1:30) — 15 minutes

**Objectives:**
- Surface common struggles
- Share discoveries
- Re-energize

**Script:**
```
Alright, pause for a moment. Stretch if you need to.

Quick progress check:
- Who's completed Steps 1-2? [Show of hands]
- Step 3-4? [Hands]
- Step 5 or beyond? [Hands]

Good mix!

What surprised you so far?
[Let 2-3 people share - listen for:]
  - How often tests run
  - Refactor step insights
  - Data structure discoveries (Map vs List)

Anyone get stuck? What helped you get unstuck?
[Usually: reading test carefully, trying minimal solution]

Any design insights?
[Password folks might mention: rules as functions
 Shopping Cart folks might mention: Value Objects]

Okay, 30 more minutes. Options:
- Continue your current kata
- If finished, try the other one
- If deep in refactoring, keep going

The TDD_REFERENCE_CARD.md is available if you need a reminder on anything.

Let's go!
```

**Actions:**
- [ ] Capture themes on whiteboard
- [ ] Validate their experiences ("Yes! That's exactly what TDD teaches")
- [ ] Note time remaining

**What Success Looks Like:**
- Participants feel heard and validated
- Common struggles are normalized
- Energy is refreshed for part 2

---

### Segment 6: Hands-on Practice Part 2 (1:30-2:00) — 30 minutes

**Objectives:**
- Complete current kata OR start second one
- Experience full cycle including refactoring

**Your Role:**
- Continue circulating
- Focus attention on people doing Step 6 (Password) or Value Objects (Cart)
- Encourage those who finished to try the other kata

**Deep Dive Conversations:**

**Password Validator (Step 6):**
```
Them: "I have 5 if-blocks. Works but feels repetitive."
You:  "What if each rule was a function? What would that look like?"
      [Pause - let them think]
You:  "Each rule is: String → Optional Error, right? Could you make a list?"
```

**Shopping Cart (Value Object):**
```
Them: "Should I validate price in ShoppingCart.addItem()?"
You:  "What if someone creates CartItem outside the cart? Who validates?"
      [Pause - let them think]
You:  "What if CartItem couldn't be created invalid? Where would validation go?"
```

**Time Checks:**
- **At 10 min (1:40):** Give heads up: "20 minutes left"
- **At 20 min (1:50):** Give heads up: "10 minutes - finish your current test"
- **At 28 min (1:58):** "2 minutes - get to a stopping point"

**What Success Looks Like:**
- Most finish Step 4-5 or beyond
- Some discover refactoring patterns
- Code is messy but working (that's fine!)

---

### Segment 7: Show & Tell (2:00-2:10) — 10 minutes

**Objectives:**
- See different approaches
- Celebrate progress
- Learn from peers

**Script:**
```
Time's up! Let's see what you built.

I'd like 2-3 volunteers to share briefly:
1. Which tests are passing?
2. Show your implementation
3. ONE interesting decision you made

Who wants to go first?
```

**What to Highlight:**
- Test organization and naming
- Simple → complex progression
- Refactorings (if they reached Step 6)
- Different valid approaches (e.g., replace vs accumulate in cart)

**Feedback Template:**
```
"I love that you [specific good practice].
Look at how tests tell a story: [point to names].
This design [refactoring] is the [pattern name] pattern."
```

**What Success Looks Like:**
- 2-3 people share
- Variety in progress levels shown
- Participants see multiple valid approaches

---

### Segment 8: Retrospective (2:10-2:20) — 10 minutes

**Objectives:**
- Solidify learning
- Connect to daily work
- Inspire continued practice

**Discussion Questions:**

**1. "What was different about writing tests FIRST vs AFTER?"**

Expected answers:
- Tests were easier to write
- Design emerged naturally
- Caught edge cases earlier
- Felt slower at first, faster later

**2. "Did you feel tempted to skip the RED step?"**

Expected: "Yes!"

Your response: "That's the discipline. RED proves the test can fail."

**3. "What design insight surprised you?"**

Reinforce:
- Password: Rules as data (Open-Closed Principle)
- Shopping Cart: Map for lookup, Value Objects for validation
- General: Small steps → emergent design

**4. "How would you apply this at work?"**

Let them think out loud:
- "That pricing calculation module..."
- "Our validation logic could be structured like this..."
- "Next util function, test first"

**Closing Message:**
```
TDD is a skill. Like any skill, it feels awkward at first.

The rhythm - RED, GREEN, REFACTOR - becomes automatic with practice.

Three takeaways:
1. Tests first - even for "obvious" code
2. Small steps - one test at a time
3. Refactor - don't skip this

Want more practice? The tdd-katas repo has 5 complete examples with commit history showing every step:
[Show link on screen]

Thanks for participating! Questions?
```

**Actions:**
- [ ] Share link to tdd-katas repo
- [ ] Share TDD_REFERENCE_CARD.md
- [ ] Mention optional office hours if offering them

**What Success Looks Like:**
- Clear takeaways articulated
- Participants know where to practice next
- Positive energy to continue learning

---

## Facilitation Tips

### Energy Management

| Time | Energy Level | Your Role |
|------|-------------|-----------|
| 0-10 min | High | Welcoming, enthusiastic |
| 10-25 min | Focused | Demonstrating, teaching |
| 25-30 min | Enthusiastic | Clarifying, motivating |
| 30-1:15 | Calm | Supportive, circulating |
| 1:15-1:30 | Re-energize | Celebrating, validating |
| 1:30-2:00 | Encouraging | Nudging toward completion |
| 2:00-2:20 | Reflective | Connecting dots, inspiring |

### Common Questions and Answers

| Question | Answer |
|----------|--------|
| "Should I write all tests first?" | "No - one at a time. Write one, pass it, then next." |
| "Can I look at the solution?" | "Try 5 more minutes first. What's the smallest step?" |
| "This feels slow. Do people really do this?" | "Feels slow when learning. With practice, faster than debugging." |
| "What test should I write next?" | "Simplest behavior it doesn't handle. Start empty, then one, then two." |
| "Is TDD for everything?" | "It shines for domain logic. Less for UI layouts or framework glue." |

---

## Success Metrics

At workshop end, participants should:
- [ ] Explain RED-GREEN-REFACTOR cycle
- [ ] Demonstrate writing failing test before code
- [ ] Recognize when to refactor
- [ ] Have experienced at least one design insight
- [ ] Be able to apply TDD to simple problems independently

---

## Post-Workshop Actions

**Immediately After:**
- [ ] Share tdd-katas repo link
- [ ] Send feedback form (3-5 questions)
- [ ] Note confusing points to improve next time

**Optional Follow-up:**
- [ ] 1 week later: Email with additional resources
- [ ] Offer "office hours" for questions
- [ ] Create Slack channel for ongoing TDD discussion

---

## Emergency Adjustments

### Running Behind Schedule

- **Skip:** Detailed mid-point discussion (keep it to 5 min)
- **Skip:** Show & tell (or reduce to 1 person, 3 min)
- **Keep:** Live demo and hands-on time

### Running Ahead of Schedule

- **Add:** 6th test to FizzBuzz demo (input 6 → "Fizz")
- **Add:** Bonus questions in retrospective
- **Add:** Quick discussion of when NOT to use TDD

### Technical Difficulties

- **Network down:** Use USB backup of repo
- **Projector fails:** Do demo at participant's screen, others gather
- **Participant computer issues:** Pair them with someone or use backup laptop

---

**You're ready to facilitate! Follow this plan, stay flexible, and remember: their success is your success.** 🚀