# Workshop Facilitator Guide — Quick Reference

**Duration:** 80 minutes  
**Format:** Live demo + hands-on practice with Password Validator or Shopping Cart katas using 3-Way Ping-Pong (mob programming)  
**Team Size:** 3 people (2 developers + you as facilitator/participant)

> **Note:** For the complete detailed plan with minute-by-minute timing, scripts, and checklists, see **WORKSHOP_PLAN.md**. This guide focuses on facilitation tips and kata-specific insights.

> **Facilitator Role:** You'll participate as the 3rd person in the rotation, experiencing TDD alongside the developers. This creates a collaborative learning environment rather than traditional top-down teaching.

---

## Essential Documents

Before the workshop, familiarize yourself with:
- **WORKSHOP_PLAN.md** — Complete schedule, scripts, and preparation checklist
- **fizzbuzz/DEMO_SCRIPT.md** — Step-by-step live demo walkthrough
- **TDD_REFERENCE_CARD.md** — Participant handout
- **SETUP_GUIDE.md** — For helping participants with technical issues

---

## Quick Preparation Checklist

### 1 Week Before
- [ ] Send SETUP_GUIDE.md to participants
- [ ] Confirm everyone completes setup and verifies `dart test` works
- [ ] Practice FizzBuzz live demo using DEMO_SCRIPT.md

### Day Of
- [ ] Arrive 15 minutes early
- [ ] Test projector/screen sharing
- [ ] Open fizzbuzz kata with git log ready
- [ ] Have solution files ready (but don't share early!)
- [ ] Write schedule on whiteboard

---

## Updated Session Structure

| Time | Activity | See |
|------|----------|-----|
| 0:00-0:05 | Welcome & Setup Check | WORKSHOP_PLAN.md |
| 0:05-0:20 | **Live Demo: FizzBuzz TDD** | fizzbuzz/DEMO_SCRIPT.md |
| 0:20-0:25 | Exercise Intro (3-Way Ping-Pong) | Section below |
| 0:25-1:05 | Hands-on Practice (Mob Programming) | Circulate & nudge |
| 1:05-1:20 | Combined Retrospective | WORKSHOP_PLAN.md |

---

## Live Demo: FizzBuzz (NEW SECTION)

**Purpose:** Show RED-GREEN-REFACTOR cycle in real-time

### Setup
1. Open `fizzbuzz/` directory
2. Have `fizzbuzz/DEMO_SCRIPT.md` open on second screen
3. Terminal ready with `dart test`
4. Reset git to initial commit: `git reset --hard <first-commit-hash>`

### Key Points to Emphasize
- **Run tests frequently** (every 30 seconds)
- **Minimal implementations** (hardcode "1" for first test)
- **Test-driven design** (algorithm emerges from tests)
- **Order matters** (check 15 before 3 and 5)

### Timing
- 0-2 min: Introduce FizzBuzz rules
- 2-4 min: Cycle 1 (input 1 → "1")
- 4-6 min: Cycle 2 (input 2 → "2")
- 6-9 min: Cycle 3 (input 3 → "Fizz")
- 9-11 min: Cycle 4 (input 5 → "Buzz")
- 11-14 min: Cycle 5 (input 15 → "FizzBuzz")
- 14-15 min: Wrap up, show git log

**See fizzbuzz/DEMO_SCRIPT.md for complete talking points and what to code at each step.**

---

## What to watch for while participating

**Your dual role:** You're both a participant in the rotation AND a gentle guide.

**Good signs:**
- Running `dart test` after every small change
- Seeing RED before touching `lib/`
- Short, focused commits (or at least talking through each step)
- Smooth keyboard passing between the 3 roles (Red, Green, Refactor)

**Gentle interventions (when it's not your turn at keyboard):**
- *"Have you run the test yet? What did it say?"* — nudge anyone writing too much code before testing
- *"Can you make it pass with even less code?"* — push toward minimal Green
- *"Now that it's Green, what could you clean up?"* — prompt the Refactor step
- *"It's time to pass the keyboard! Let's rotate."* — enforce the rotation

**When it's your turn:**
- Model the behavior you want to see (run tests frequently, minimal code, think aloud)
- Ask questions rather than giving answers: *"What's the simplest thing that could work here?"*
- Show vulnerability: *"Hmm, I'm not sure. What do you think?"*

---

## Feature A: Password Validator — facilitator notes

**Likely first implementation** (all rules as if-blocks):
```dart
ValidationResult validate(String password) {
  final errors = <String>[];
  if (password.length < 8) errors.add('Must be at least 8 characters long');
  if (!password.contains(RegExp(r'[A-Z]'))) errors.add('Must contain at least one uppercase letter');
  // ... etc
  return ValidationResult(isValid: errors.isEmpty, errors: errors);
}
```

**The refactor insight to guide toward (Step 6):**
Each rule is just a function `String? Function(String)`. They can live in a list.
Adding a new rule = adding one function. No touching existing code.
This is the Open-Closed Principle — same insight as Gilded Rose's Strategy pattern.

**Talking point:** *"If you had 20 rules, how readable would 20 if-blocks be? What would you do?"*

---

## Feature B: Shopping Cart — facilitator notes

**Likely first implementation** (List-based):
```dart
final List<CartItem> _items = [];

double subtotal() => _items.fold(0, (s, i) => s + i.price * i.quantity);
```

**The Map insight (Step 3 — remove by name):**
When participants try to implement `removeItem(name)` with a List, they'll write a `.removeWhere()`.
This works, but nudge them: *"What data structure makes 'find by name' really natural?"*
Let the remove-by-name test drive them toward `Map<String, CartItem>`.

**CartItem validation (Step 5):**
Many will put validation in `addItem()`. Ask: *"What if someone creates a CartItem and passes it somewhere else? Who validates it then?"*
This conversation leads naturally to Value Objects.

**Bonus design question:**
The duplicate name test has no right answer. Both "replace" and "accumulate" are valid.
The point is: TDD forces you to decide, and the test documents the decision permanently.

---

## Closing discussion questions

1. *"What was the first test you wrote? Why that one?"*
2. *"Did your design change as you added more tests? How?"*
3. *"Did you ever feel tempted to skip the Red step and just write the code?"*
4. *"How did the 3-way ping-pong dynamic change how you wrote code?"*
5. *"What would have been different if you'd designed the class first, then written tests?"*

---

## Common questions and answers

**"Can I write all the tests first, then implement?"**
Not quite — TDD is one test at a time. Write one, watch it fail, make it pass, then the next.
Writing all tests upfront is a different practice (it's fine, but it's not TDD).

**"What if I don't know what test to write next?"**
Ask: *"What's the simplest behavior this thing should have that it doesn't have yet?"*
Start with the empty/zero case. Then one item. Then two. Then edge cases.

**"Is this realistic? Do people actually do this for real code?"**
Yes — especially for domain logic (pricing, validation, calculations).
It's less common for framework glue code, and that's okay. Apply it where behavior matters most.