Saturday I had the honor of attending another code retreat hosted by Agile Minds at Qframe. This code retreat was a bit special to me as we were only with 6 men. Though it was a small code retreat, it was the best one I’ve attended so far!
We did a total of 5 sessions so no luck breaking the world record ;-) Every session was pretty intense.
The main thing that I’ve learned from this code retreat is that TDD as you meant it can be allot more useful than I initially thought. Let me first in layman’s terms explain to you what it is.
The most important thing in TDD as you meant it, actually in TDD in general is to have NO design plans up front. Your mind must be clear of any predefined design choices! The main focus is to let your test drive you design.
Then what is the difference with just normal TDD? Well in TDD as you meant it you actually have no choice then to let the design flow out of your tests. This is because you write the actual implementation code inside your test. Here is a small example in function of Conway’s Game of Life:
1. The first step is to write one failing test:
[TestMethod]
public void ALivingCellCanDie()
{
object cell = new object();
// implementation code comes here
Assert.IsNull(cell);
}
As you can see in this method we don’t assume anything. We didn’t assume that the cell would be a Boolean, there is not Game object, no Grid object, no Cell object, no design what so ever. We are just testing the fact that the notion of a cell can die.
2. Make the test pass by writing the implementation code in the test:
So our test is red, now we can implement it. The implementation would become:
[TestMethod]
public void ALivingCellCanDie()
{
object cell = new object();
cell = null;
Assert.IsNull(cell);
}
That just looks like rubbish don’t it? Well yeah… but keep in mind we have nothing at this point, and the first 2, 3 to 4 tests will look silly but then the patterns start emerging :-)
3. Create a new implementation function by:
1. Doing an extract method on the implementation code
2. Move the implementation code into an existing implementation method
Since we don’t have an existing method we’ll extract a new one:
[TestMethod]
public void ALivingCellCanDie()
{
object cell = new object();
cell = Die();
Assert.IsNull(cell);
}
private object Die()
{
return null;
}
4. Only create new methods in the test class
This is important because you’re not sure up front where these methods belong. You might think that the Die method could belong to some kind of assassin object, but maybe another test will convince you that it doesn’t!
5. Only create implementation classes to provide a destination for the extracted methods.
After a while when you keep doing this you’ll might notice that some methods belong to each other, at this stage you can start creating an implementation class for them. But be sure that you have enough proof that shows you that these implementations belong to that object.
6. Populate implementation classes by doing move method from a test class into them
You should only move the methods out of your test class. There shouldn’t be any need to adapt the methods so they fit inside this object. When you feel the need for changing the implementation code then you might be doing too much.
7. Refactor as required
At this stage you might have some cleaning up to do, then this is the time to do it. You have green tests so you’ll always be sure that your code works.
I must admit that at first this is a very bitter pill to swallow. It’s slow and tormenting but in the end you’ll produce very clean, testable and loosely coupled code. Understandably this might be too difficult and slow to use in a production environment and I know that when you’re on a deadline this could prove to be too much overhead. But I encourage people that have some spare time left to try this out. It will provide you with a new angle to tackle your problems and you’ll probably end up with a design you never expected.
I’ve enjoyed this code retreat allot and will probably subscribe to more of them. If you’re interested then register here.
Big thanks to Erik and Adrian for hosting the code retreat!
Till next time :-)
