tdd-workshop/WORKSHOP_PLAN.md

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. 🚀