Red-Green-Refactor



Drawing: Tim Ottinger

Photo: Libby Ottinger

Cleanup: Jeff L.


We show flash cards to students in order to help them completely ingrain a concept, to the point where they don't think about something, they just know it. The classic flash card presents a student with a vocabulary word or a math expression for which we expect almost immediate recognition and response. I show you the Spanish vocabulary word "acuario" and you blurt out "fish tank!"


So, red-green-refactor. By definition, TDD says write the tests first. They should fail, since you've not built the functionality that the tests specify, and a GUI test tool will show red at this point. That's useful feedback that tells you to write just enough code to get all existing tests to pass; the GUI test tool shows us green. Finally, you can ensure that the code has an optimal design during a refactoring step, since you have tests to give you the confidence to change things. Spend a few minutes, improve the design, and re-run your tests, which should all still be green. The entire cycle should take about 5 minutes on average, and no more than 10 minutes.


If you've been doing TDD for more than a few days--I mean really doing it and not writing code first and then sneaking in a few tests afterward and then telling people "I got muh TDD's done"--this cycle should be starting to sink in. Those of us who've done TDD a little longer--maybe a few months--don't think twice about it. Red-green-refactor feels like the natural way for us to build software.



  • Red - A common mistake for newbies to TDD is to gloss over the need to see the test fail first. It's part of keeping on course; the red is extremely valuable feedback that tells us our assumptions still hold true. Once in a while, they won't, and you'll have saved yourself a lot of time by finding that out immediately.

  • Green - Keep rough track of how long it takes you to derive a solution that passes all your tests. If you're taking 5-10 minutes on average, or more, start figuring out ways to take smaller steps.

  • Refactor - You should always take advantage of the refactoring step. Even if you added perfect code (that doesn't duplicate any other code in the system), treat the refactoring step as "mandatory bonus time." Poke around the area you're changing. Get rid of a warning. Rename a test. Improve the readability of an existing method. Follow the boy scout rule: Make things a little better when you leave than they were when you arrived. Note that the refactor step doesn't necessarily represent a single green test run: You should look to decompose refactoring efforts into even tinier steps, getting a rapid succession of green bars before moving on.


4 comments:

  1. The other real advantage of having red first is that it shows your test configuration is right. If you've not named your test or test file correctly, or left off some attribute, then the test may not be running at all.

    Sometimes a programmer thinks he's got a green bar when in fact the test was never run. That's also why my first test is usually assert(False) or the like. Test-after programmers make this mistake all the time and don't even know it.

    ReplyDelete
  2. this is amazing stuff,
    is there one place where I can find all of the flashcards?

    I want to print a whole bunch of them, and brand them with my clients logo...

    ReplyDelete
  3. This is the place you can find them right now. We're looking to publish the whole set as a deck of cards, and a book with one mini-chapter per card.

    Of course the cards have our copyright, and we need to have a talk about branding, ownership, and attribution. But we're pleasant people (well, Jeff is, and I like to think I am) and I'm sure we can work out details with you.

    ReplyDelete
  4. I want a t-shirt with this drawing on it. Seriously.

    ReplyDelete

Note: Only a member of this blog may post a comment.