Ward Cunningham stopped the exercise. He’d been teaching Test-Driven Development (TDD) to a bunch of student but they were spending far too much time trying to make their failing tests pass. Writing large, overly complicated unit tests isn’t how we test-drive code. Ward asked the students to restart the exercise but this time he said there would be a competition: “The pair of students who finish the exercise AND have the shortest longest period in the red wins.”
Shortest longest red? What’s that? In TDD, when a test fails, we say it’s red. Your next step is to make the test go green by writing the code to pass the test. It should not take too long to go from red to green, since you are only test-driving micro-pieces of behavior. Refactoring happens after your test is green. We implement this red, green, refactor cycle over and over again as we test-drive solutions. We can measure the time during which we had the longest period of red (failing tests). If we can compare our longest red to that of every other pair doing the exercise, we can determine who had the shortest longest red.
To measure how long they were “in the red”, Ward suggested that one programmer in the pair take on the additional responsibility of being the time keeper. They’d keep time of any period during which one or more tests were red. By the end of the exercise, every pair had finished programming the solution and had data about their longest period in the red. Sure enough, one pair had the shortest longest red. But they said they felt guilty for winning. “We think we cheated because we would start the timer once we had a failing test but if it went past a minute and still wasn’t green, we would simply revert the code and start again.” Ward assured them that such an approach was not cheating. They were learning to test-drive code in small steps.
Red vertical bars depict duration of test failures
TCR (Test && Commit || Revert)
If you are a TDD practitioner and haven’t heard about Kent Beck’s new workflow called TCR, you ought to take a look. TCR is different from TDD. It’s more radical for starters. The “R” in TCR means Revert. If you write code that doesn’t pass your tests it is automatically deleted. Goodbye code, let’s try that again! It’s a little like those winning students in Ward’s TDD class who reverted when it took too long to get to green. But with TCR, a failing test is never the goal. Instead, you endeavor to make small, incremental steps that keep your tests running green. Kent writes:
If you don’t want a bunch of code wiped out then don’t write a bunch of code between greens. Yes it can be frustrating to see code disappear but you almost always find a better, surer, more incremental way of doing the same thing.
Taking a step in which you “write a bunch of code” reveals you have more to learn about what Kent calls the better, surer, more incremental way. Ward’s students needed to learn that lesson and his shortest longest red competition helped. TCR goes further. It add incremental guard rails to help you program in that better, surer, more incremental way. And it insists that the time of your shortest longest red is zero.
