Full TDD cycle

By now almost everybody knows Red – Green – Refactor. It’s established.

However recent PPPPP test-workshop (enjoyed it greatly! check it out!) was the first time I spoke against this. Feel free to label this as nitpicking on my part but for me that cycle long now has been insufficient.

TDD_FullCycle

It’s a mighty fine place to mention, that the idea isn’t mine, I once searched for a good image with standard TDD cycle and found a graphic that showed something similar to what I have above. If you’re curious, try searching for image “bunny TDD cycle” and look at first find.

Why?

  • refactor never was such a major phase like writing failing test or adding implementation – then why make it look like such?
  • there are times it’s skipped entirely yet standard graph tells to do it every time – this may sound like nitpicking, but people ask me about it often enough
  • refactor is about making code more readable, you never move away from green and you don’t end refactor on red
  • key shift in TDD is thinking – and my cycle showcases this: going from red to green is “HOW do I do that?” while going from green to red is “WHAT do I do next
  • there are two states in TDD, not three – red (broken) and green (working)
  • red – green – refactor omits compile errors which I believe are key in making newbies see why generating code is trivial and thus lowering TDD entry-barrier
  • it happened for me that I wrote a passing test, yet standard graph has no places for it
  • I like Petri nets

In more details…

I made a fuller explanation, if you wish, using Prezi. I intend to use that from now on when I’ll be teaching people about TDD, or showing my take on it’s cycle and why it differs from traditional one.

Advertisements

2 Comments

  1. Hi,

    I believe the refactor phase is mentioned right next to red and green, because people tend to neglect it. Of course, you do not really refactor every time! But I think it is good to remember about this phase so you at least THINK about it. You know, taking a look at your code and deciding if you like it or not. And 9 on 10 cases you will simply go with the next test. Still, you should stop and think.

    “refactor is about making code more readable, you never move away from green and you don’t end refactor on red” – oh, ok 🙂 I understand, but I think this is nitpicking. 🙂 Yeah, right the standard diagram might suggest that after refactor you are red again.

    About passing tests. Yes, there is no place for them on original diagram, yet we do add them.

    Ok, my general comment is like this. The red-green-refactor is great because it is short and stays in memory. Even if it is not 100% correct, it brings so much good, that I would leave it the way it is. Ok, fine, you can have more sophisticated, and even more correct (realistic) diagrams, but they are nowhere close to the simplicity of the original one. And that is the problem. The original diagram brings clear message. And I believe this is the most important thing.

    cheers!

    P.S. Kudos for being brave enough to question the teachings of testing gurus! 😉

    1. Hi Tomek and thanks for taking the time to write this! 🙂 Good to have authors on test matters commenting on that post!

      Ad refactor. Notice two sentences you used here:
      1) refactor phase is mentioned right next to red and green, because people tend to neglect it
      2) 9 on 10 cases you will simply go with the next test

      I’m reading the latter as “9 out of 10 times it’s OK to go with next test as there’s nothing to refactor”. If that’s what you intended, then I see you agree with that NOT being a major phase. If you meant it the other way “most people nearly always forget about refactoring” then yes, and this is kinda like false positive problem. You have three rules – red, green, refactor, but in reality, you have only two, the third doesn’t matter, it’s not really a rule, it’s just a cherry on a pie… “just forget it” comes easily after.

      I also honestly never liked any replies I heard (or have given) to question “I don’t have anything to refactor and I’m on the refactor phase, what do I do?” – and the follow-up explanations of refactor “not really being a phase”, or being optional or what not. If nobody gave satisfactory answer (myself included!) then no wonder refactor ends up neglected! Herein lies the weakness of the established cycle IMO.

      Ad simplicity of the cycle. You nailed it here – I can’t describe my graph in three words (though I certainly will try to describe it simply). Yet I should say here two things:
      1) I published this not to “eliminate” or “replace” the red-green-refactor, but because for me the established cycle long now was insufficient and I didn’t like it, DESPITE it’s easy-to-grasp simplicity.
      2) for me TDD is not mechanical. There’s no “step A, step B, step C, repeat”. TDD involves thinking, mechanical procedures do not. Key shift is in thinking and this drives your code. One does not simply test into Mordor, as they say, you don’t add just any failing tests.

      I simply think newbies should be pointed in a slightly different direction. Instead: “after green, refactor, you shift between three states”, I’d go for: “you alternate between working (verified) and not working (unverified) code while you design and add features, in as few elegant code lines as readable and needed to make the code work as intended”. And yeah – that’s still not as short as “red – green – refactor”. 😉

      Well, the size of this comment means I need to add more to the post! 🙂 Thanks Tomek!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s