Why Unit Test-Driven Development is Important

People have written a ridiculous amount about the advantages of test-driven development.  I won’t even bother linking to articles about it, just Google it and you’ll see about a million hits.  What almost none of those articles talk about is how unit-test driven development can help in an agile environment where acceptance testing is difficult.I have several clients who struggle with getting coding and acceptance testing done within each iteration.  I don’t want to go into the factors that make this difficult/impossible, let’s just go with the fact that it is pretty much impossible for them to do it effectively.  As a result, they end up coding in one iteration, perhaps starting testing that iteration, but finishing the testing in the next iteration.  Obviously this is not ideal, but they don’t have a lot of choice.

I spent part of a day this past week talking to one of the teams doing this and realized that although they write unit tests, they aren’t using UTDD (unit test-driven development).  Instead they are writing code, then writing the tests to test the code.  I started asking them about their continuous build process and found out that a build was done on each code check-in, but none of the unit tests were run after code was checked in.  I pointed out that a nightly build which ran the automated unit tests would be beneficial since it would catch errors created by newly checked-in code.  They immediately saw the value in that and are going to implement it as soon as possible.

On my way home I began to wonder how many teams and organizations really can’t do testing in the same iteration as coding (for whatever reason).  It seems to be more common than I thought it was.  When I went down that line of thought I realized implementing a good UTDD practice in those organizations would be well worth it.  If the code that is being tested later is at least of high quality because the unit tests were written ahead of time in order to make sure the code was of high quality and to ensure the code had at least a fighting chance of matching the user story, shouldn’t that make acceptance testing go better?  I think I knew this, but this past week really made it hit home for me.  As a result I now have a new rule to use as an agile coach:

If you can’t do testing in the same iteration as coding, it is even more important to utilize UTDD and a nightly build that runs all unit tests!

Will the resulting quality be different than if organizations doing testing after coding did not utilize UTDD?  I could make the case that it would be better using UTDD, but even if it is not better it will be completed faster.  While I don’t have data to back that up, I think most people would recognize that insufficient unit testing will lead to many back and forth cycles between QA and Dev.  In addition, use of UTDD to help make sure the intent of the code is correct will cut down and the back and forth cycles caused by misunderstood requirements.  It seems the process will be shorter using UTDD than not using it, regardless of the quality question.

Is your organization one of those that cannot do testing within the same iteration as the coding?  If so, would UTDD help?  Leave a comment and let me know your thoughts.  I’d like to dig into this further and perhaps come up with some actual data to support my theory.