When TDD was first suggested, there were many who were dubious about the wisdom of having developers write tests of their own code. Among the objections raised was that developers will slow down if you burden them with new tasks, namely writing the tests as well as the code.
This seems logical. Give someone more to do, and they will take longer to do it. But the truth is that TDD actually increases velocity once the team gets over the initial learning curve.
How can this be? This is true for three reasons.
First, TDD makes developers confident. They tend to be less hesitant when everything they do is being constantly confirmed or corrected. It also encourages small steps which helps to eliminate wasteful confusion and task-switching.
Second, TDD helps developers to avoid writing unnecessary code. Developers will sometimes “chrome” the system when they are not certain about exactly what the code needs to do. Defining behavior in tests first helps them to avoid this. When the test passes, they’ve done enough.
Third, TDD is really about creating a specification, which we were going to do anyway. It’s not really new work, but a new way to do existing work. It is a way that can be confirmed at any time in the future to be correct.
TDD speeds up the team.
-AMAZONPOLLY-ONLYAUDIO-START-
This is Scott Bain. Visit us at www.netobjectives.com.
-AMAZONPOLLY-ONLYAUDIO-END-