Ed Gibbs talks about the difficulty in selling Test Driven Development (TDD) to his development staff. I agree with him 100%. I’ve been trying to express the value I’ve found in this technique for quite some time now and am not getting the best reception or adoption from my staff. We still find the majority of the tests are written after development has been completed and at a time when most of the relevant details that should be in the test cases are forgotten due to release schedules.

My first foray into TDD was invaluable and taught me quite a bit about the value of writing tests WITH the code you are writing. I was writing a set of object oriented Python scripts that managed our CVS repository. These scripts were originally written in PERL and I had begun learning Python and wanted a real project to use it on. This was also a very good project for object orientation and objects are something that I really despised doing in PERL, so Python was the obvious choice.

In the decision to rewrite these scripts in Python, I found that Python came with PyUnit and thought it was a great opportunity to try TDD since I had just read Kent Becks book, Test Driven Development: By Example. I’m one of those people that can force himself to try something new out of sheer will, even if I don’t quite believe that it will have benefit.

During the development of these scripts, I created an object model in which I could manage multiple source repositories and perform actions on them such as checking out a workarea, branching the repository, and creating new work areas with new build numbers assigned to them. The application wound up being more than I thought it would be, but I stuck with the TDD approach and wrote my tests.

When we made the decision to move to the Subversion Version Control System, I had quite a bit of refactoring to do in order to support both the CVS repository and the Subversion repository in order to reduce cutover time (we basically had to change a property file when we had completed to move to the new source control system). The tests that I had written during original development were invaluable in reducing the development time in refactoring the base source control objects to support the Subversion system and we wound up with a fairly robust application that supported the original requirements of the CVS repository on Subversion.

The best part is that I knew that all of my requirements were met, because I had the tests to run and prove it.

Even with this (I think pretty compelling) example, the TDD approach has been a hard sell. I think that reason #1 in Eds post is the reason. People just think it will take more time. It does take more time, but not that much and from my experience you really don’t notice it that much. As a matter of fact, for me it added a little extra excitement watching the tests pass at regular intervals during the development cycle. Furthermore, if the time is included in the original schedule, who cares if it takes more time? If you budgeted the time, you’ve set expectations!

Still after all of this, there is resistance. I would be very interested in hearing from others who have successfully implemented this in their organizations. There are instances in which ‘leading by example’ still doesn’t work, as people fear changing what they do and find any reason they can not to. Add to that that if the one “leading” isn’t involved in day to day project work, he doesn’t have the credibility as someone who is. It looks like just another “change” the manager wants to make.

So, if you’ve made this change, I’d be really grateful if you could post your experiences in the comments section of this blog. Tell me about what you did to make this change and, more importantly, the benefits you received as a result of the change. I’d love to read them and have a place where my staff can come and read them as well.