Goal: Practice test-first programming.
Time: 20-60 minutes.
(Use only the most important stories, or cut down to small teams, to make the game play shorter.)
Introduction:
A stoplight goes "green-yellow-red." Test-first programming does the same.
- Green: Initially, the program works.
- Yellow: Add a test that calls a new (unimplemented) feature; you get a syntax error because the method isn't even defined yet.
- Red: You add a stubbed version of the routine, which fails the test (presumably).
- Green: You fix the routine, and all tests run.
If the lights go out of order, it may be a sign that something is wrong:
- Green to red: This happens for a new test on an existing routine. "No license": Don't add new code without putting in its test first.
- Green to green: OK (even desirable) when refactoring, where we don't want to change features in a way that breaks a test. "Failed to yield": It's not OK if it's a new test and new code – we need to see the test fail once before seeing it pass, so we can be sure the new code is what made the test pass.
- Yellow to green: "Ran red light": Make the test fail once before making it work.
- Red to red: "Speeding": Take smaller steps if this happens very often.
Material:
- Blank paper. (One or two colors.)
- A set of red, yellow, and greeen circles. (Can cut out from colored file cards).
- Post-it notes representing tickets.
Setup:
- Decide whether to use individual programmers or pairs.
- Choose someone to be the moderator, representing the compiler and the test harness. This could either be one person who serves a number of programmers, or let people in a pair take turns.
- Give each programmer a green circle and two pieces of paper (one for test code, one for production code).
Play:
- Programmers execute the cycle: write some test or production code, and give the code and the current circle to the compiler.
- The moderator decides the status, and returns the code and the appropriate circle. (Moderator shouldn't be very picky about syntax mechanics.)
- If the circle is out of order, the moderator can issue a ticket. As a police officer, they can listen to the excuse and decide if there's a good reason, or if the person can be let off with a warning.
- No license: "green to red for new code"
- Failed to yield: "green to green when not refactoring"
- Ran red light: "yellow to green means test never failed"
- Speeding: "red to red too often"
- Repeat the cycle until a small bit of functionality is added. (Trade partners so everybody gets to try.)
Debrief:
- What do green, yellow, and red mean?
- Did you consistently follow the green-yellow-red cycle?
- Why do we want to see a yellow light? [Ensures that the system doesn't think a class or method exists yet. Some teams don't bother taking yellow lights.]
- Why do we want to see a red light? [Assures us that the test failed once, and that adding new code fixed it. This lets us believe the new code is what made the difference, and acts to test the test.]
Source:
(William C. Wake, based on my original metaphor of the Test-First Stoplight, inspired by watching Kent Beck apply the TDD approach.)