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.
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.
- 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.