Initial commit: Complete TDD workshop materials
- Workshop documentation (WORKSHOP_PLAN, FACILITATOR_GUIDE, etc.) - FizzBuzz kata with demo script (git history to be recreated) - Password Validator kata with demo script and solution - Shopping Cart kata with demo script and solution - Setup guide and TDD reference card for participants
This commit is contained in:
commit
c3355063f2
26 changed files with 4725 additions and 0 deletions
520
WORKSHOP_PLAN.md
Normal file
520
WORKSHOP_PLAN.md
Normal file
|
|
@ -0,0 +1,520 @@
|
|||
# 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.** 🚀
|
||||
Loading…
Add table
Add a link
Reference in a new issue