Red, green, refactor cycle – smallest TDD iteration

by Pawel Olesiejuk on 13th September 2011

Red Green Refactor Cycle As I wrote before, TDD is a methodology. It requires a set of disciplines, and one of them is ‘red, green, refactor’. It is about writing test first, make it pass and then refactor the code. Sounds crazy? Let’s take a closer look.

‘Red’ – write failing test

This means that you have to have a failing test first. You can’t write any production code before ‘red’. Why? Because you have to know this test could fail in some circumstances and you have to know which change makes it pass. I’m sure that you’re thinking ‘How the hell can I write a test for nothing?! You’re crazy, man!’ So, I have to calm you down. I’m not crazy (let’s assume that I’m not). Sure you can write a test for something that does not exist. Who forbids you to do that? Compiler? Screw it! Write simple test, e.g. [csharp] [TestFixture] public class CalcTests { [Test] public void AddTwoInts_BothZeros_ShouldReturnZero() { var sut = new MyCalculator(); var result = sut.add(0,0); Assert.AreEqual(0, result); } } [/csharp] Try to run your test (yes, I’m almost sure that I’m not crazy). Oh, ‘build fail’? Ok, try to fix the build. Use ReSharper, ‘alt + enter, enter’ on every error. You don’t use ReSharper? Bad for you, but you could use VS goodness or CodeRush. If you think that it would be faster if you’d written this class first, you’re wrong :) Good, it’s compiling. Try to run your test. Exception NotImplementedException (it’s because ReSharper stubs created method with ‘throw new NotImplementedException()’). Good, building but failing. It’s ‘red’. :)

‘Green’ – make the test pass

When we have compiling but failing test we can write some production code to satisfy our test and nothing more. Write code that is only needed to make the test pass by replacing the line which throws exception with ‘return 0’ statement. Now, try to run the test again. WOW, passed! Do you think this is a bad solution? Doesn’t work fine? Sure it works fine, because the test passed. There is YAGNI principal (YAGNI stands for You Ain’t Gonna Need It) which says ‘don’t write more than you need at this moment’. If you are sure you need more, write test for it and then implement this functionality. There is another TDD principal, which says that ‘red’ stage should only take a while. Ken Beck in his book wrote ‘quick green excuses all sins’. After we make it green we’ll have time for refactoring at the same time knowing that our app works, without a doubt, properly!

‘Refactor’ – clean up your code

Look at your code. Do you like it? Do you want to eat it? Do you want to…? Ok, I think you got my point. If your answer to any of these questions was ‘no’, you should do something about that. I don’t like instantiation in the test method. Right now it’s not a problem, but I know that I’ll write more tests in this class, so I think that I should create a field called _sut and instantiate it in SetUp method, like that: [csharp] [TestFixture] class CalcTests { private Calc _sut; [SetUp] public void Before() { _sut = new Calc(); } [Test] public void AddTwoInt_BothZero_ShouldReturnZero() { var result = _sut.Add(0, 0); Assert.AreEqual(0, result); } } [/csharp] You can introduce variables/constants for all these zeros but I think it is readable enough as it is right now. And what about the production code? It looks fine. Yeah, really! ‘return 0’ isn’t a bad solution for now. According to triangulation method you have to write another test to force change (there are others methods for ‘going forward’, but about this another time). You can’t change it for e.g. ‘return a + b’ because it isn’t refactoring. Refactoring is changing code without changing its functionality. So that’s it! This is TDD! This assures you that your tests are trustworthy and cover all possibilities, but about this next time.

The colorful iteration

Whole ‘red, green, refactor’ thing is about iteration, little programming cycles and fast feedback. When we write failing test we say ‘hey, my app should do that!’ Then we make it come true as fast as we can. It’s like in this game where you have to pass the ball to the next player before it ‘burns’ you. When you make a test pass, then you can relax and do refactoring. Change implementation, introduce design pattern and extract class or whatever you want. You have confidence that your code works all the time and that you didn’t break anything. This is the smallest programing cycle; this is exactly what TDD is about.

Have you ever heard about ‘red, green, refactor’ cycle and have you got your own opinion? Feel free to share with us in a comment.

Remarks to code:
‘sut’ is my convention to name my tested objects (it stands for System Under Test) because I want to distinguish them from other objects (e.g. stubs)