TDD is great, but it can be tough going at times.
Over the past ten years or so, I have had a somewhat rocky relationship with TDD. There have been times when I employed it religiously, and others when I consciously chose not to. When I first tried it, working through Uncle Bob Martin’s famous bowling game kata, I immediately fell in love. I wasn’t sure why at the time, but it felt right. I started using it in the workplace, but before long, in an environment where TDD was not actively encouraged, I fell back into old habits.
Since that time, I have gained a better understanding of why TDD ‘feels right’. In particular, there are two benefits which for me overshadow all others:
- If you do TDD right, you end up with a well-designed loosely coupled system.
- When you reach that inevitable point of wanting to refactor what you have done, you can do so with a reasonable level of confidence.
On a slightly deeper level, TDD also protects us against our own human nature. We programmers often have a natural tendency to get caught up in the creative process. The instant gratification monkey can take over. Sometimes, and with some people, this can lead to fantastically innovative and beautiful designs. But without a suite of unit tests, the result is not protected against inevitable future updates. Our brains just aren’t as good as we would like to think at anticipating the possible results of a modification to our code.
The problem is that many of us, myself included, didn’t learn to write code in the TDD way. When I was in uni, nobody had ever heard of TDD. And this brings us to the biggest challenge in the adoption of TDD practices – breaking old habits.
Perhaps the best summary of the realities of TDD I have come across is in a discussion on stackoverflow (this actually refers to unit testing rather than TDD, but the same concept applies):
Unit testing is a lot like going to the gym. You know it is good for you, all the arguments make sense, so you start working out. There’s an initial rush, which is great, but after a few days you start to wonder if it is worth the trouble. You’re taking an hour out of your day to change your clothes and run on a hamster wheel and you’re not sure you’re really gaining anything other than sore legs and arms.
This makes sense. Whenever someone starts out on a new exercise regime or a new diet, or in fact tries to adopt any new habit, one of two things tends to happen. Either they begin with determination and enthusiasm but then fall back into old habits, or they doggedly repeat their new habit again and again until it becomes second nature and it is no longer a huge effort to keep it up.
The same applies with TDD. If we believe it is beneficial, we need to keep doing it, and accept that during an initial adaptation phase at least, we will be tempted to abandon it and go back to doing things the way we are used to.
A recent blog post which has proved very controversial, and has also proved that the debate is still alive and kicking, suggested that TDD is dead. I disagree, with the title of the post at least. TDD has its place in software development – it works. But that doesn’t mean that we should pretend that changing our working habits to adopt TDD is easy.
When the pressure is on, and particularly when we are surrounded by other programmers who are still coding ‘the old-fashioned way’, it can be really tough to stick to TDD. And there are times when TDD probably isn’t the best idea – for example, if our manager actively disagrees with the approach, or we are confident that for this particular line of code, maybe a getter or a setter, it would offer little value. Flexibility and common sense should prevail. But when we aren’t doing TDD, we should at least be honest with ourselves about our reasons – is it that TDD would genuinely not be appropriate at this time, or are we just being lazy?
Should I or shouldn’t I? At this moment in time, I feel I should.
The post TDD – Should I or Shouldn’t I? appeared first on The Proactive Programmer.
