The “Call Your Shots” TDD Workflow

Kent Beck’s TCR workflow experiment has generated some good discussion. Rachel Carmena has documented several TDD workflows. I’d like to add an approach that I’ve used for a while: “Call Your Shots”.

Call Your Shots

If you’re playing pool seriously, you don’t just count any ball that falls in a hole; you have to say what you’re trying to do before you shoot.

Or imagine that picture of Babe Ruth, pointing out where his home run hit would go. (It’s still controversial as to whether this happened, but work with me here.) Real or not, we’re going to borrow the attitude.

The Call Your Shot approach has two key elements: calling your shot, and backing up.

“Calling your shot” is making a prediction out loud – “Should be red” or “Should be green”. I started doing this when I’d pair, just to make sure we were on the same page. But I’ve found it important to be explicit even when I’m solo – it’s too easy to say “oh, that’s ok, cuz …” and ignore that this means I didn’t know what I was doing (in a small way). The old magicians were right: speaking aloud gives something more power.

“Backing up” is using undo to get back to a previous state. I’ve been watching James Shore’s series “Let’s Code: Test-Driven JavaScript” (which I recommend), and I’ve noticed that he uses Undo quite liberally. Why spend a lot of time in an unstable red state, when you can be green for the price of a few (Undo) keystrokes? Kent’s “Revert” is an even stronger way of getting this effect.

The Workflow

Call Your Shots works within the Red-Green-Refactor model of Test-Driven Development.

Make It Red (Test)

  • Write a test you expect to fail.
  • Call your shot: Say “Should be red” out loud.
  • Run the tests.
    • If the new test is green, you’ve either picked something that was already implemented or you made an error in your test; back up and fix it.
    • If it’s red, you’ve tested your test (at least a little); continue.

Make It Green (Implement)

  • Write code that you expect will make the tests pass.
  • Call your shot: Say “Should be green” out loud.
  • Run the tests.
    • If a test is red, undo and try again.
    • If you’re not able to easily implement this code, back up to the top and start over with a simpler test (what Kent Beck calls a Child Test).
    • If green, continue.

Make It Gold (Refactor)

  • Apply a refactoring.
  • Call your shot: Say “Should be green” out loud.
  • Run the tests.
    • If any are red red, back up and try again.
    • If they’re green, you can either make another refactoring move or go to the top and write the next test.

Observations

Enforced? Years ago, I modified a JUnit runner to have two buttons that ran the tests – “Expect Red” and “Expect Green”. (It made a buzzing noise if your prediction was wrong.) I let this go after an upgrade, but I’ve tried to keep the attitude.

Source control? You can certainly blend this workflow with source control. I’ve seen three basic approaches (depending on the team):

  1. Commit occasionally. Commit at a green bar, having implemented one or more tests and/or one or more refactorings. The feature is done, or at least some substantial part of it.
  2. Commit only if clean. Some teams commit only when they feel the code is clean (on a green bar, but only if they’ve either completed refactoring or decided it’s not needed).
  3. Commit on every green. Some teams commit at a very fine-grained level, after every move that leaves the tests green.

Undo only? Sometimes I see what was wrong right away, and just type the fix rather than doing an undo. (Perhaps I’m lazy or over-confident in short-cuts:) Occasionally, I do use a debugger or print trace statements. I don’t think that’s a particularly good thing; maybe I should explicitly do those as a spike, and re-do the work “properly”.

Green tests? Some tests are intended to run green the first time. Perhaps we think we’ve implemented something fully, and we want to give it a complicated test just to make sure it handles realistic cases. The principle is the same: Call “Should be green” and react accordingly.

Related Items