Monday 18 May 2009

An Unexpected(?) Advantage of TDD

So there are a lot of advantages to using TDD, they are well documented and there are plenty of people who extol its virtues.

One of them however has resonated with me of late. And that is how it effectively builds a living document of the implemented functionality of your system.

I am working on a personal project, and the time I can spend on it is quite sporadic. Between work and a young family, time to code for fun is quite broken - 10 minutes here, an hour there, a weeks break, another 10 minutes and so forth. It doesn't make for much of a flow.

But what I have found is, by sticking to TDD and by using test names that are informative that I have built a living document of what I've implemented. So when I come back to the code even for a moment I know where I am. Run the tests, and green, there is all my functionality.

Better yet, the breaks force me to revisit my naming, and I actively refactor the code (including the tests) to try and make it more readable.

I've also found that by invoking the "if its not green at then end of the session then ditch it" rule quite effective too. Now you might say that if you only have five minutes to work on it then chances are you're not going to get to green. And a lot of the time its true - but before I stop, I roll back to green.

Now at first that seems counter productive, as the tests will show where its broken and you know where to come back to - but in practice I have found that it actually tends to mislead me, particularly if I have been away from it for a while. So better to return to a clean slate. Then what I find is that my subconscious tends to chew on the problem for a while, and when I come back to it I find my flow much quicker.

So its just another reason to use TDD and descriptive test names.

2 comments:

Andy said...

If you finish your session on a green, then write the next test and have it fail, you have an effective bookmark as to what you were planning as the next step.
If when you come back to it, you have other ideas, you lose nothing by deleting it.

ie.
@Test
public void shouldFlurgleTheWotsit() {
fail("Left off here 2009-05-18");
}

Glen said...

I am usually in a hurry to end a session - typical scenario is a 2 year old dismantling my MythTV box (or worse), so rollback is generally my quickest option ;)

I have used that technique a couple of times, but usually ended up deleting it, so I stopped. But its what is the most appropriate for the individual.