Reading Joseph Ottinger’s blog; “Scary thought: maybe those who say they can’t do TDD are right” I would think that any development manager or newbie looking to implement TDD would be pretty concerned about some of the comments made, particularly this one:
“Most developers do *no* TDD at all. It's about time we started listening to these people instead of trying to lecture them.”
Obviously this is a controversial issue. It can quickly degenerate into a tirade of arguments about why TDD would or would not work in certain organizations and types of projects.
The obvious thing I see here is an education issue. TDD is a big topic with plenty of reference material available on the web, and people interpret different parts of it in different ways. Sure, some people may have had bad experiences with TDD depending on the culture of the organization, especially if they are not fully committed to a TDD approach, which can quickly result in them slipping back into more traditional development methodologies. Or, from a technical standpoint, some organizations find it difficult to implement a TDD approach in, say, an embedded environment.
However, the organizations I have seen that have successfully implemented a TDD methodology are the ones willing not only to invest the budget to train people in TDD and its culture, but to have the patience to work through the first months of hurdles and issues due to the different way of thinking that TDD requires.
The whole ‘agile revolution’ is not a silver bullet, but there are an increasing number of reports and case studies (for example: Success Rate of Agile Software Development in Agile Magazine - Spring ed. or http://www.objectmentor.com/omSolutions/agile_customers.html ) on many projects that show an increase in the number of projects being delivered on time and at a higher quality level. TDD is a big part of this revolution.
There are various ways to implement TDD, and a number of different keys to success. A simple favorite of mine is this: if a bug is reported, write a unit test to prove the bug exists. Once the unit test passes, the bug will be eliminated and should never re-occur [assuming you run all unit tests as part of your integration build].
A reference work I see on the desks of nearly all customers I visit is Michael C. Feathers’ “Working With Legacy Code”, which has many examples of applying TDD to legacy projects, rather than only new projects, something that was missing from a lot of last year’s conference topics when discussing TDD, in my opinion.