My thoughts too. It seems logical to suggest that TDD would reduce the number of bugs in the product that's being tested, at least somewhat. However, the true question may be if the time spent writing those tests (longer that the time spent writing code?) is worth it when looking at the number of problems it prevented.
I believe the practicality of TDD depends on too many factors to make statements about it in general. Is your project well defined (good for TDD) or a cool little idea that changes and morphs every day or two (bad for TDD). Is it large scale and complex (good for TDD) or quite simple (TDD may be a waste of time here). There are more factors of course too.
Thanks for the feedback. See my comment to roryokane above about the time spent on testing.
I agree with you about the practicality of TDD. For instance, recently, I was prototyping an upcoming feature involving a new library. The feature was quite different in terms of functionality (compared to the existing features). In this case, I did not use TDD as the prototyping was morphing (to use your words) quite a lot and I was trying to learn more about the library.
I believe the practicality of TDD depends on too many factors to make statements about it in general. Is your project well defined (good for TDD) or a cool little idea that changes and morphs every day or two (bad for TDD). Is it large scale and complex (good for TDD) or quite simple (TDD may be a waste of time here). There are more factors of course too.