418 lines
13 KiB
Markdown
418 lines
13 KiB
Markdown
# TDD Workshop - Complete Plan
|
|
|
|
**Title:** Test-Driven Development Workshop: From Theory to Practice
|
|
**Duration:** 80 minutes
|
|
**Format:** In-person, hands-on
|
|
**Target Audience:** 3-person team (2 developers + facilitator)
|
|
**Language:** Dart
|
|
**Primary Goal:** Build muscle memory for the RED-GREEN-REFACTOR cycle through deliberate practice using 3-Way Ping-Pong (mob programming)
|
|
|
|
> **Facilitator Note:** You'll participate as the 3rd person in the rotation rather than observing from the sidelines. This creates a collaborative learning environment where you model TDD practices while gently guiding the team.
|
|
|
|
---
|
|
|
|
## Pre-Workshop Preparation
|
|
|
|
### 1 Week Before
|
|
- [x] Confirm participant count and send calendar invite
|
|
- [ ] Share repository link with setup instructions (SETUP_GUIDE.md)
|
|
- [x] Ask participants to complete setup and verify `dart pub get` + `dart test` work
|
|
- [x] Prepare a backup laptop with environment pre-configured
|
|
- [x] Review this plan and the FACILITATOR_GUIDE.md
|
|
|
|
### 1 Day Before
|
|
- [x] 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 | 5 min | Welcome & Setup Check | Facilitator-led |
|
|
| 0:05 | 15 min | Live Demo: FizzBuzz TDD | Live-coding |
|
|
| 0:20 | 5 min | Exercise Introduction (3-Way Ping-Pong) | Facilitator-led |
|
|
| 0:25 | 40 min | Hands-on Practice (Mob Programming) | Team coding |
|
|
| 1:05 | 15 min | Combined Retrospective | Facilitated discussion |
|
|
|
|
---
|
|
|
|
## Segment-by-Segment Guide
|
|
|
|
### Segment 1: Welcome & Setup (0:00-0:05) — 5 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:05-0:20) — 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:20
|
|
|
|
---
|
|
|
|
### Segment 3: Exercise Introduction (0:20-0:25) — 5 minutes
|
|
|
|
**Objectives:**
|
|
- Explain the two kata choices
|
|
- Introduce 3-Way Ping-Pong workflow
|
|
- Get the team started on a single shared screen
|
|
|
|
**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
|
|
|
|
Pick what sounds interesting to your team.
|
|
|
|
Today we're using "3-Way Ping-Pong" - a mob programming format that maps perfectly to RED-GREEN-REFACTOR:
|
|
|
|
1. Developer A (RED): Uncomment ONE test, run it, watch it fail. Pass the keyboard.
|
|
2. Developer B (GREEN): Write minimal code to make it pass. Pass the keyboard.
|
|
3. Developer C (REFACTOR): Clean up the code if needed. Then write the next test (uncomment it). Pass the keyboard back to Developer A.
|
|
|
|
Rotate roles with each cycle. Everyone gets to experience all three phases.
|
|
|
|
Use one shared screen. The person with the keyboard is the "driver" - everyone else navigates.
|
|
|
|
Questions? Good. Choose your kata and let's start with Step 1!
|
|
```
|
|
|
|
**Actions:**
|
|
- [ ] Show README files on screen briefly
|
|
- [ ] Ensure team has chosen one kata
|
|
- [ ] Confirm they understand the rotation: A (Red) → B (Green) → C (Refactor + next Red) → A (Green) → ...
|
|
- [ ] Start 40-minute timer
|
|
|
|
**What Success Looks Like:**
|
|
- Team has chosen a kata
|
|
- Files are open on shared screen
|
|
- Roles are assigned (A, B, C)
|
|
- First developer is ready to uncomment first test
|
|
|
|
---
|
|
|
|
### Segment 4: Hands-on Practice (0:25-1:05) — 40 minutes
|
|
|
|
**Objectives:**
|
|
- Build RED-GREEN-REFACTOR muscle memory
|
|
- Experience how tests drive design
|
|
- Practice mob programming rotation
|
|
- Encounter and resolve "stuck" moments
|
|
|
|
**Your Role:** Participate as the 3rd person in the rotation. When it's your turn, model good TDD practices. When it's not your turn, gently guide with questions.
|
|
|
|
**Good Signs:**
|
|
- Tests running frequently
|
|
- Seeing RED before touching lib/
|
|
- Smooth keyboard passing between roles
|
|
- Team discussing design together
|
|
- Each person respecting their role (Red only writes test, Green only makes it pass, Refactor cleans up)
|
|
|
|
**When It's Your Turn at the Keyboard:**
|
|
- Model the behavior: run tests frequently, write minimal code, think aloud
|
|
- Show vulnerability: "Hmm, what's the simplest thing here?"
|
|
- Narrate your thinking: "I'm going to run the test first to see it fail..."
|
|
|
|
**When Others Have the Keyboard (Gentle Guidance):**
|
|
|
|
| Situation | What to Say |
|
|
|-----------|-------------|
|
|
| Writing code without test | "Have you run the test yet? What did it say?" |
|
|
| Developer doing too much in their role | "Remember, you're on GREEN - just make it pass. We'll clean up in REFACTOR." |
|
|
| Not refactoring | "See any duplication? What could we extract?" |
|
|
| Stuck on data structure | "What makes 'find by name' really easy?" (Shopping Cart) |
|
|
| Keyboard not being passed | "It's time to pass the keyboard! Let's rotate." |
|
|
| Overthinking | "What's the simplest thing that could work?" |
|
|
|
|
**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:40):** Team should be on Step 2-3
|
|
- **At 25 min (0:50):** Team should be on Step 3-4
|
|
- **At 35 min (1:00):** Give heads up: "5 minutes left - finish your current test"
|
|
|
|
**What Success Looks Like:**
|
|
- Steady rotation and test running
|
|
- Team experiencing "aha!" moments together
|
|
- A few stuck moments that resolve with nudging
|
|
- Energy remains positive and collaborative
|
|
- Team completes at least Steps 1-4
|
|
|
|
---
|
|
|
|
### Segment 5: Combined Retrospective (1:05-1:20) — 15 minutes
|
|
|
|
**Objectives:**
|
|
- Solidify learning
|
|
- Reflect on the 3-way rotation experience
|
|
- Connect to daily work
|
|
- Inspire continued practice
|
|
|
|
**Script:**
|
|
```
|
|
Great work! Let's reflect on what we just experienced.
|
|
|
|
Since you all worked on the same code together, let's discuss:
|
|
|
|
1. Which tests are passing now?
|
|
2. Show your implementation - what does it look like?
|
|
3. What interesting decisions did you make as a team?
|
|
```
|
|
|
|
**Discussion Questions:**
|
|
|
|
**1. "How did the 3-way ping-pong rotation help enforce TDD discipline?"**
|
|
|
|
Expected answers:
|
|
- Forced us to stay in role (couldn't skip ahead)
|
|
- Made the cycle explicit and visible
|
|
- Kept us from writing too much code at once
|
|
- Everyone had to understand what was happening
|
|
|
|
**2. "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
|
|
|
|
**3. "Did you feel tempted to skip the RED step?"**
|
|
|
|
Expected: "Yes!"
|
|
|
|
Your response: "That's the discipline. RED proves the test can fail."
|
|
|
|
**4. "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
|
|
|
|
**5. "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"
|
|
- "We could do mob programming for complex features"
|
|
|
|
**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
|
|
|
|
The 3-way rotation you just experienced is a great way to learn TDD as a team.
|
|
You can use this format for any new feature or complex problem.
|
|
|
|
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:**
|
|
- [ ] Capture key insights on whiteboard
|
|
- [ ] 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
|
|
- Team reflects on both TDD and mob programming benefits
|
|
- Participants know where to practice next
|
|
- Positive energy to continue learning
|
|
|
|
---
|
|
|
|
## Facilitation Tips
|
|
|
|
### Energy Management
|
|
|
|
| Time | Energy Level | Your Role |
|
|
|------|-------------|-----------|
|
|
| 0-5 min | High | Welcoming, enthusiastic |
|
|
| 5-20 min | Focused | Demonstrating, teaching |
|
|
| 20-25 min | Enthusiastic | Clarifying, motivating |
|
|
| 25-1:05 | Collaborative | Participating in rotation, modeling TDD, gentle coaching |
|
|
| 1:05-1:20 | Reflective | Celebrating, 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 retrospective discussion (keep it to 10 min)
|
|
- **Reduce:** Live demo to 12 minutes (skip one cycle)
|
|
- **Keep:** Hands-on practice time (this is the core learning)
|
|
|
|
### 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
|
|
- **Extend:** Hands-on practice time
|
|
|
|
### Technical Difficulties
|
|
|
|
- **Network down:** Use USB backup of repo
|
|
- **Projector fails:** Do demo at team's screen, gather around
|
|
- **Computer issues:** Use backup laptop or share one machine
|
|
|
|
---
|
|
|
|
**You're ready to facilitate! Follow this plan, stay flexible, and remember: their success is your success.** 🚀
|