From 5b4df9ebd61e079647592d3c90bdd7e806025c48 Mon Sep 17 00:00:00 2001 From: fiatcode Date: Thu, 16 Apr 2026 00:22:22 +0700 Subject: [PATCH] Add initial slides for TDD workshop presentation with custom styles and navigation --- FACILITATOR_GUIDE.md | 36 +- README.md | 17 +- WORKSHOP_PLAN.md | 308 +++++---------- slides.html | 909 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 1043 insertions(+), 227 deletions(-) create mode 100644 slides.html diff --git a/FACILITATOR_GUIDE.md b/FACILITATOR_GUIDE.md index 18522f0..877cf41 100644 --- a/FACILITATOR_GUIDE.md +++ b/FACILITATOR_GUIDE.md @@ -1,10 +1,13 @@ # Workshop Facilitator Guide — Quick Reference -**Duration:** 2 hours -**Format:** Live demo + hands-on practice with Password Validator or Shopping Cart katas +**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 @@ -37,14 +40,11 @@ Before the workshop, familiarize yourself with: | Time | Activity | See | |------|----------|-----| -| 0:00-0:10 | Welcome & Setup Check | WORKSHOP_PLAN.md | -| 0:10-0:25 | **Live Demo: FizzBuzz TDD** | fizzbuzz/DEMO_SCRIPT.md | -| 0:25-0:30 | Exercise Introduction | Section below | -| 0:30-1:15 | Hands-on Practice (Part 1) | Circulate & nudge | -| 1:15-1:30 | Mid-Point Check-in | WORKSHOP_PLAN.md | -| 1:30-2:00 | Hands-on Practice (Part 2) | Circulate & nudge | -| 2:00-2:10 | Show & Tell | 2-3 volunteers | -| 2:10-2:20 | Retrospective | WORKSHOP_PLAN.md | +| 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 | --- @@ -77,17 +77,26 @@ Before the workshop, familiarize yourself with: --- -## What to watch for while circulating +## 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:** +**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?"* --- @@ -142,7 +151,8 @@ The point is: TDD forces you to decide, and the test documents the decision perm 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. *"What would have been different if you'd designed the class first, then written tests?"* +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?"* --- diff --git a/README.md b/README.md index 94e408e..7d71370 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # TDD Workshop -**A hands-on, 2-hour workshop for learning Test-Driven Development through deliberate practice.** +**A hands-on, 80-minute workshop for learning Test-Driven Development through deliberate practice.** --- @@ -11,8 +11,8 @@ This workshop teaches the RED-GREEN-REFACTOR cycle through: 2. **Hands-on practice** (Password Validator or Shopping Cart) 3. **Group reflection** and retrospective -**Target audience:** Developers familiar with TDD concepts but lacking hands-on practice -**Duration:** 2 hours +**Target audience:** 3-person team (2 developers + facilitator) +**Duration:** 80 minutes **Language:** Dart --- @@ -118,12 +118,11 @@ tdd-workshop/ 2. **Choose a kata:** - **Password Validator:** Rules-based validation, interesting refactoring - **Shopping Cart:** Stateful domain object, data structure decisions -3. **Follow the workflow:** - - Uncomment one test at a time - - Make it RED (watch it fail) - - Make it GREEN (minimal code to pass) - - Refactor (clean up duplication) - - Repeat +3. **Follow the 3-Way Ping-Pong workflow:** + - **Dev A (RED):** Uncomment one test, run it, watch it fail. Pass the keyboard. + - **Dev B (GREEN):** Write minimal code to pass. Pass the keyboard. + - **Dev C (REFACTOR):** Clean up the code. Write the next test (RED). Pass the keyboard. + - Rotate roles and repeat ### Kata Instructions diff --git a/WORKSHOP_PLAN.md b/WORKSHOP_PLAN.md index dbdd5ca..df39aff 100644 --- a/WORKSHOP_PLAN.md +++ b/WORKSHOP_PLAN.md @@ -1,25 +1,27 @@ # TDD Workshop - Complete Plan **Title:** Test-Driven Development Workshop: From Theory to Practice -**Duration:** 2 hours (120 minutes) +**Duration:** 80 minutes **Format:** In-person, hands-on -**Target Audience:** Developers familiar with TDD concepts but lacking hands-on practice +**Target Audience:** 3-person team (2 developers + facilitator) **Language:** Dart -**Primary Goal:** Build muscle memory for the RED-GREEN-REFACTOR cycle through deliberate practice +**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 +- [x] 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 +- [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 -- [ ] Practice FizzBuzz live demo (use DEMO_SCRIPT.md) +- [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 @@ -59,20 +61,17 @@ | 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 | +| 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:10) — 10 minutes +### Segment 1: Welcome & Setup (0:00-0:05) — 5 minutes **Objectives:** - Ensure everyone can run tests @@ -118,7 +117,7 @@ Let's see this in action. --- -### Segment 2: Live Demo - FizzBuzz (0:10-0:25) — 15 minutes +### Segment 2: Live Demo - FizzBuzz (0:05-0:20) — 15 minutes **Objectives:** - Demonstrate RED-GREEN-REFACTOR in real-time @@ -144,16 +143,16 @@ Let's see this in action. - Participants see the rhythm clearly - At least one "aha!" moment visible (nodding, note-taking) -**Time Check:** Should finish by 0:25 +**Time Check:** Should finish by 0:20 --- -### Segment 3: Exercise Introduction (0:25-0:30) — 5 minutes +### Segment 3: Exercise Introduction (0:20-0:25) — 5 minutes **Objectives:** - Explain the two kata choices -- Clarify workflow -- Get people started +- Introduce 3-Way Ping-Pong workflow +- Get the team started on a single shared screen **Script:** ``` @@ -169,61 +168,67 @@ SHOPPING CART: - You'll discover when to use Map vs List - Good for practicing: Value Objects, data structure decisions -Both are good. Pick what sounds interesting. +Pick what sounds interesting to your team. -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 +Today we're using "3-Way Ping-Pong" - a mob programming format that maps perfectly to RED-GREEN-REFACTOR: -Pairing optional - if you pair, try "ping-pong": -- Person A writes test -- Person B makes it pass -- Switch roles +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. -Questions? Good. Choose your kata and start with Step 1! +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 -- [ ] Start 45-minute timer -- [ ] Let people move to pair up if desired +- [ ] 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:** -- Everyone has chosen a kata -- Files are open -- First test is being uncommented +- 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 Part 1 (0:30-1:15) — 45 minutes +### 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:** Circulate, observe, nudge with questions (don't give solutions) +**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/ -- Small commits or at least incremental changes -- Discussing design (if pairing) +- 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) -**Interventions (Use these phrases):** +**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?" | -| 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?" | +| 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) | -| Hardcoding too long | "Try another test with different input. What happens?" | +| 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?" @@ -233,161 +238,49 @@ Questions? Good. Choose your kata and start with Step 1! - "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) +- **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 typing and test running -- Some "aha!" moments (facial expressions, discussions) +- Steady rotation and test running +- Team experiencing "aha!" moments together - A few stuck moments that resolve with nudging -- Energy remains positive +- Energy remains positive and collaborative +- Team completes at least Steps 1-4 --- -### 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 +### 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. "What was different about writing tests FIRST vs AFTER?"** +**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 @@ -395,25 +288,26 @@ Expected answers: - Caught edge cases earlier - Felt slower at first, faster later -**2. "Did you feel tempted to skip the RED step?"** +**3. "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?"** +**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 -**4. "How would you apply this at work?"** +**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:** ``` @@ -426,6 +320,9 @@ Three takeaways: 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] @@ -433,12 +330,14 @@ 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 @@ -450,13 +349,11 @@ Thanks for participating! Questions? | 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 | +| 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 @@ -499,21 +396,22 @@ At workshop end, participants should: ### 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 +- **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 participant's screen, others gather -- **Participant computer issues:** Pair them with someone or use backup laptop +- **Projector fails:** Do demo at team's screen, gather around +- **Computer issues:** Use backup laptop or share one machine --- diff --git a/slides.html b/slides.html new file mode 100644 index 0000000..46b3c72 --- /dev/null +++ b/slides.html @@ -0,0 +1,909 @@ + + + + + + TDD Workshop — 80 Minutes + + + + + + +
+ +
+ +
+
+

+ TDD
+ WORKSHOP +

+

80 minutes · 3-Way Ping-Pong · Hands-on Practice

+
+
+ + +
+
+

The TDD Rhythm

+
+
+
1
+
Red
+
Write failing test
+
+
→
+
+
2
+
Green
+
Make it pass
+
+
→
+
+
3
+
Refactor
+
Clean up code
+
+
→
+
+
↻
+
Repeat
+
Next test
+
+
+
+
+ + +
+
80
+
+

Today's Schedule

+
+
+
0:00
+
+

Welcome & Setup

+

5 minutes · Verify environment

+
+
+
+
0:05
+
+

Live Demo: FizzBuzz

+

15 minutes · Watch TDD in action

+
+
+
+
0:20
+
+

Exercise Intro

+

5 minutes · 3-Way Ping-Pong explained

+
+
+
+
0:25
+
+

Hands-on Practice

+

40 minutes · Mob programming

+
+
+
+
1:05
+
+

Retrospective

+

15 minutes · Reflect & discuss

+
+
+
+
+
+ + +
+
+

3-Way Ping-Pong

+
+
+
A
+
Red
+
Uncomment test
Watch it fail
+
+
→
+
+
B
+
Green
+
Write minimal code
Make it pass
+
+
→
+
+
C
+
Refactor
+
Clean up
Next test
+
+
+

+ Rotate roles with each cycle · One shared screen +

+
+
+ + +
+
+

RED Phase

+

Write a failing test

+
    +
  • Uncomment ONE test
    • +
  • Run dart test
    • +
  • Watch it fail (proves it can fail)
    • +
  • Pass the keyboard
    • +
+
+ // Uncomment this test
+ test('returns 1 for input 1', () {
+   expect(fizzbuzz(1), '1');
+ }); +
+
+
+ + +
+
+

GREEN Phase

+

Make it pass (minimal code)

+
    +
  • Write the simplest code that works
    • +
  • Don't worry about perfection
    • +
  • Run tests to confirm GREEN
    • +
  • Pass the keyboard
    • +
+
+ String fizzbuzz(int n) {
+   return '1'; // Hardcode is OK!
+ } +
+
+
+ + +
+
+

REFACTOR Phase

+

Clean up the code

+
    +
  • Remove duplication
    • +
  • Improve names
    • +
  • Tests stay GREEN
    • +
  • Uncomment next test (back to RED)
    • +
  • Pass the keyboard
    • +
+
+
+ + +
+
+

Choose Your Kata

+
+
+

Password Validator

+

Rules-based validation · Refactoring challenge · Open-Closed Principle

+
+
+

Shopping Cart

+

Stateful domain object · Data structures · Value Objects

+
+
+
+
+ + +
+
+

TDD Principles

+
    +
  • Tests first — Even for "obvious" code
    • +
  • Small steps — One test at a time
    • +
  • See RED — Proves the test can fail
    • +
  • Minimal GREEN — Hardcoding is OK initially
    • +
  • Refactor fearlessly — Tests protect you
    • +
+
+
+ + +
+
+

+ Ready to
+ Practice? +

+

Let's build muscle memory for TDD

+
+
+
+ + +
+
+
+ + +
+ 1 / 10 +
+ + +
+ ← → arrows or click to navigate +
+ + + +