Why developers are reluctant to use Test Driven Development (TDD)?

Some people can tell you about my passion for software development and for trying to do things in the best possible way.

As a consequence of this I’m always looking on Twitter for interesting conversations. Recently I found an interesting question tweeted by Dave Farley, author of one of the famous books about continuous delivery (Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation) and one of the authors of the Reactive manifesto. He asked this question:

Is TDD too hard to implement for some developers? Or are developers reluctant to adapt?

And the conversations around his question were really interesting: people were pointing out many different reasons people don’t like or are resistant to use TDD. Starting from education, where there is no special interest (at least at the University level) to explaining how better programs can be written (in terms of better quality or maintainability) and thus, resulting in better software. At least in my experience, I don’t remember taking any class around TDD or eXtreme Programming practices but I remember learning about OOP, design patterns or as a maximum on how to write a unit test.

Besides education, the majority of the examples you can find on the Internet do not help a lot in order to explain the benefits of applying or using TDD. Most of the examples are easy (programming katas) and therefore you can’t compare nor see how to start using TDD on your day-to-day project where you are facing with an unmaintainable legacy or untestable code.

There are many more reasons on why developers don’t like to try TDD, and I think it is also because the discipline is hard at the beginning. You have to almost “forget” what you know, and force yourself to do things differently. Probably in all your professional experience you had to make tests (with a strong “if” in some companies this is still something unusual) and always you make them at the end of the development, when you have your feature working (supposedly, because you cannot verify it). And yes, TDD is completely opposite to this way of working, so you have to “fight” yourself, thinking that you’re trying to do things differently than you’ve been doing all your life and whether this is the right way to do it or not. But, do not panic, trust me, suddenly all the pieces fit 😉

I can see myself years ago arguing about why we should use TDD if it does not matter when you write your tests? Well, after some time (weeks? months?) practicing by myself with several katas, attending community events, and trying to use it in real projects, just like that, I finally got used to it. As a habit, like riding a bike. We don’t know how, suddenly one day, you go from not knowing how to hold your balance, to riding your bike alone, without help from anyone.

Today, one can say that I have become a strong advocate of this methodology and whenever I can, I try to follow its principles. I must also say that, having been doing pair programming with colleagues who could help me to make the way, something must have helped me, and personally I think a lot. So thank you to all those who participated in this learning!

PD: Expect more articles with my arguments around why TDD makes sense to use it (and master it) as a professional software engineer 😉