tdd-workshop/WORKSHOP_PLAN.md

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

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