>If we're ignoring a practice that guarantees an improvement in the quality of our code and the speed of our delivery without a very good reason, then we are be

>If we're ignoring a practice that guarantees an improvement in the quality of our code and the speed of our delivery without a very good reason, then we are being unprofessional. Very good reason? Yes, it's very costly and only catches a certain sort of error. Would clients prefer 25% more features or the set you have with a full suite of unit tests? Many would prefer the 25% more features. Additionally, with that same amount of money you could spend doing TDD, you can do any number of OTHER practices which ALSO increase code quality, including, formal design reviews, informal design reviews, informal code reviews, formal code reviews, desk checking of code, automated analyzers, running through profilers, running through memory leak detectors, modeling, prototyping, component testing, integration testing, regression testing, system testing, beta testing and many more techniques. All of these take TIME and MONEY. TDD is just one of the many things you can do if your client/employer cares about code quality, and not necessarily the best thing. I mean formal inspections (according to code complete 2, pg 470) and formal design reviews are always much more efficacious at finding bugs than unit testing (which is what TDD revolves around). According to that, we shouldn't be spending the quality improvement time doing TDD based procedures then, but instead pouring over the code in review sessions. Secondly, many other techniques CAN yield better results than TDD, and in less time (but don't always). These include protoyping, personal desk checking, system tests, and beta tests with more than 1000 users. So many adherents of methodology X don't accurately scope in the tradeoffs of their costs, etc, when advocating their system. Morning scrumm meetings sacrifice people who want to have long (and therefore, more unpredictable commutes). People who like automated function comment headers don't count how much time people spend filling in those header boxes. People who like variable naming conventions don't spend enough time understanding what that does to the people who have to constantly change the way they name them. People who like full waterfall don't understand the morale crushing cost of huge changes after large design/documentation pushes like that. I could go on and on. TDD has costs. Those costs aren't necessarily worth it. Sometimes they are, sometimes they're not. The people who say "it saves you time" are full of crap. It may, sometimes, save some people, some time. All the tests, if they're at all worthwhile, both take time to write and maintain. I've been on projects which use it and don't, and while there was a lower defect rate on certain types of bugs, those weren't always very important, nor was the time cost of writing the tests worth it, as those projects had several high value features which couldn't be completed due to time.