114 karma · joined April 30, 2012
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.
Regarding the first part of your comment: I don't think that is the case. We don't usually add backend code without UI (I don't have a measurement for this unfortunately). Our bug tracker or tracking method has not changed since we first installed Trac in 2007.
TDD definitely adds more development time (especially in the beginning where you have to learn the practice and put test frameworks in place). However, I think it's good because I see it as a good investment: you spend time upfront writing test instead of spending more time afterwards troubleshooting broken software. Even better, the test suite can catch regressions long after a feature has been implemented, so you get even more value then. That really helps as a development team grows.
1) Do you measure the defect counts over time? And if so can you share it? 2) What is your platform (web?)?
Thanks!
JP