I agree with Spolsky on this one; and I cant help feeling TDD is like agile. One of those things cool companies and corporates use to sound "cutting edge".
We used TDD for a few projects (and agile too) and found it does slow you down no end.
And it also ultimately doesn't catch many useful bugs and problems. We still had to go through the usual end-point testing cycles.
We write unit tests for any of our API's and also for some of our core code; but only after original versions are in place. They are supposed to catch any mistakes or errors in futures we enhance and evolve the programming so we don't break backwards compatibility.
I think it really does come down to what works best for your teams though. Im sure plenty of people find TDD a great addition to their arsenal.
But at the end of the day it's just a buzz word like everything else - and we've found that by avoiding those kinds of things we produce good, solid, working code at a fast (not necessarily faster pace) - but with less headaches :)
The thing with unit testing is, a lot of the time it's used to try and make a weakly-typed language with uncontrollable side-effects behave like a strongly typed language in which pure functions can be written.
A team lead who doesn't understand the above sentiment is at best only going through the motions with unit testing.
We used TDD for a few projects (and agile too) and found it does slow you down no end.
And it also ultimately doesn't catch many useful bugs and problems. We still had to go through the usual end-point testing cycles.
We write unit tests for any of our API's and also for some of our core code; but only after original versions are in place. They are supposed to catch any mistakes or errors in futures we enhance and evolve the programming so we don't break backwards compatibility.
I think it really does come down to what works best for your teams though. Im sure plenty of people find TDD a great addition to their arsenal.
But at the end of the day it's just a buzz word like everything else - and we've found that by avoiding those kinds of things we produce good, solid, working code at a fast (not necessarily faster pace) - but with less headaches :)