TIL: Helping People Understand TDD by Writing a Story

At an agile gathering in St. Louis a few years ago, I learned a pretty nifty game/simulation to help people (especially those unfamiliar with programming) learn basic concepts of TDD. Taught by the ever-so-sensational Amitai Schleier and Mark Balbes, I’ve been meaning to write about this for more than a year. Thanks to a curious member over at the Agile Uprising forums, I finally put it to words. With all credit to Amitai and Mark, this fun little simulation is a good addition to your mentoring toolkit.

To help people of all skillsets understand the practices, and value, of a test-first approach to writing software, this game teaches people through writing a story together. That’s right, TDD with words, using whatever language (e.g., English words) the audience understands.

(You should know: In my experience, this simulation resonates far greater with folks who do not have much, if any, background writing code… since it doesn’t require knowledge of reading code (or programming in general), it’s easy to follow along. For people who are comfortable writing code, I’ve found this to be less effective… they’d rather just work with the real thing.)

Here’s the basic outline to get you started. There’s plenty of room to innovate, experiment, or just ask Amitai and Mark how to do this properly. Let’s pretend Arthur and Ford are facilitating:

1. Arthur projects a dual-screen for the audience containing two side-by-side text editor pages (Word, notepad, etc.). The right page is labeled, “CODE” and the left page, “TESTS.”
2. (Optional, but helpful: Facilitate the exercise with a partner to also demonstrate good pairing practices, such as Llewellyn Falco’s strong-style. One person speaks the context of the solution, the other person writes the “code.” Take turns rotating.)
3. Ford announces the goal of the exercise: “Let’s write a short story together using TDD. By the end of our time together, we’ll have a complete story about…”
   • A boy and his dog…
   • Two friends at the beach…
   • A bird learning to fly…
   • etc
4. They begin by demonstrating for the audience how to work as a pair, as well as TDD’s “red-green-refactor” loop.
   • Arthur: “Well, any good story about [a boy and his dog] needs a title. We’ll need a test to ensure a page centered title exists at the top of the screen.”
   • Ford: In the “test” window, writes something along the lines of, “A title is centered at the top of the screen.”
5. Arthur asks the audience to “run the test.” Does it pass? [Audience says, “No!”] Sweet! We have a failing test!
   • Arthur: “OK, let’s make the test pass by adding a title.”
   • Ford: In the “code” window, types anything suitable, like “story about a dog.”
6. Ford asks the audience to again “run the test.” Does it pass? [Audience says, “yes!”] Nice!
7. Arthur spots an opportunity to “refactor the code.”
   • Arthur: A couple of hoopy froods we are! And I think we can refactor the code. We’re not sure yet what a great title would be for our story. What if we simplify the code to a shorter title?”
   • Ford: Changes the code (the title) to the letter “X.”
   • Does it pass the test? [Audience realizes “X” also passes the test, but with far less code!]
   • This gives a very visual and clear demonstration of the red-green-refactor loop, plus the principle of writing clean, simple code via TDD as a design mechanism, too. Often times, this is an “Ohhhhhh, I get it” moment for people.
8. They continue along by inviting pairs from the audience to continue writing the story. As facilitators, Arthur and Ford help teach by assisting with ideas for tests when people are stuck or go astray. Some useful tests they observe might look like:
   • “It’s a short story, so it should be equal to 100 words…”
   • “It’s about a dog, so the word ‘dog’ should be used at least once…”
   • “A story needs an author…”
   • “We need to know when the story has ended…”
   • “Each word in the title needs to be capitalized…”
   • etc.
9. With each update to the story, and as pairs of people cycle through the exercise, they write a new (failing) test and (passing) code – while making sure the entire story remains in the “green.” In the end, the group creates a little story and people leave with an understanding of what developers are doing with their code when using TDD.
10. A post-workshop Pan Galactic Gargle Blaster is in order and Ford helps himself to a second round.

Do you have an idea to improve this workshop? I’d love to hear how you might take this to the next level!

UPDATED 5/13/18:
Corrected this article to provide proper, and well deserved, credit to Mark Balbes (Mark and Amitai co-facilitated the workshop I attended.) Amitai shared a link from the original session which includes screenshots and notes. Check it out!