I want to explain why I find Test-Driven Development so important to modern software development teams.  There are many reasons, and it will take a few articles for me to go through them.  I’d like to start with a reason that may be the most important and is fairly easy to understand.

I have found that one of the most important things that TDD does, is that it protects an individual developer’s ability to create new code without harming the existing code.  When TDD is a team discipline, that team must run all of the unit tests and see them pass before they merge their code in with the rest of the team’s code.  When a developer knows that they may have broken something by what they add, it creates a high level of anxiety for a truly professional developer.  We often take pride in our work as developers and when our code breaks everything, it is very shameful to us.  Obviously, it is also very unproductive.  It is one of those hidden costs that makes software take longer to make and causes it to be less reliable for those who use it.  It can actually harm people when our new code breaks some of the old code that we didn’t realize would be affected.

It may be hard for those who aren’t software developers to understand the impossibility of merely reading the code in order to figure out if what we add will break something.  Even the most confident developer makes a typo.  All it takes is one letter or even a missing semi-colon in to harm the code.  I recently broke code by having the wrong case.  The letter was right but its case was not.  Trying to write code without a way to check it, is like having a job at which you must walk a tight-rope all day.  It’s clearly not sustainable.

The discipline of test-driven development, causes all team members to write their tests before they write their code.  This isn’t just a random and cruel requirement.  It’s a practice that ensures that every programmer’s intentions are both stated and preserved.  This may be the fundamental benefit of TDD.  It’s a way to communicate a programmer’s intentions to all future programmers.  That way, when a future developer makes a change, they add their new intentions and make sure all of the existing intentions are still being met.  In this light, TDD is fundamentally a discipline that enforces communication between developers.

It’s important to note that even when a programmer works alone, they often forget their own previous intentions for the software!  Our work requires that we focus.  It doesn’t take long for us to exceed our own ability to remember the details.  By practicing TDD, the intentions we preserve may be our own.

This is just one of the benefits I have witnessed over the years as I have practiced TDD.  It turns out that it also can improve our requirements process, serve as documentation, improve software design and promote the software’s internal quality, but this one reason alone would probably be worth the effort to me.