(1) Testable code (i.e. all promised features at least "work")
(2) Less "careless/oversight/lazy" bugs
(3) More time to spend on finding "real" bugs
(4) More time testing and less time haggling
(5) Less time spent on test system maintenance
(insert yours here)
However, this can also be accomplished using a DCUT (Design, Code, Unit Test) approach regardless of methodology used. Well written unit tests not only provide code verification it is also a key component of the developers personal feedback loop. There is one huge benefit I see TDD has brought to the table; the developer is forced to write the unit test before he actually writes the code. This has always been the sticky point in every software house I have worked in, Unit Tests! Or lack there of.
There are exceptions to every rule. I have known many software engineers that write unit tests; they follow (no matter what methodology is being employed) a Design, Code, Unit Test approach. Their outputs were _ALWAYS_ free of "obvious" bugs. These, in my opinion, look at software development as an engineering process and not an artistic one; although creativity is a must. In contrast I have known many software developers that do not write unit tests and, further, feel they are unnecessary use of time. I believe there lies the difference; Software Engineer vs Software Developer; Engineer vs Artist.
I see TDD as one of the ignitors of a "pattern training and modification" for the way developers think about unit testing and developing in general that was very needed in the software industry.
This ties into the another discussion, is SW Development a Manufacturing process? If you are not writing unit tests how will you measure the output of your function? You wouldn't so in the case where SW development is considered an art. If, on the other hand, you're writing unit tests, then you'll be able to measure your output and hence be following a more manufacturing like, engineering process.
While [TDD] has been a success in getting a lot of folks in the software development industry to embrace unit testing, DCUT has been employed by friends and colleagues of mine and I'm sure most of you since the 80's and 90's; it just was not called TDD. These are the folks that, in my opinion, have always understood software development. Unit tests are like a personal feedback loop. One in which I as a developer can measure my output and decide success or failure. Any developer that does not unit test, is employing what I call "faith development" practices and is the weakest link in the organization; in my opinion and regardless of methodology / development process being used.
Consider the following Software Development Life Cycle diagram with which TDD, as well as any other software development methodology, I contend, can be used.
|Fig 1 - SDLC should accomodate any development methodology|
Your thoughts, comments and feedback is welcomed.