See the comment somebody made elsewhere about "money driven development". The cost-benefit ratio has to make sense.
I've frequently heard criticism of TDD most loudly by those who don't write unit tests, do unit tests manually, or intend to write them "after they get everything working." This last excuse is most egregious because one rarely has time to go back and write tests for something that is working because there will always be something more pressing than addressing the minor technical debt of writing "unneeded tests."
No, it is entirely orthogonal to having unit tests, that's exactly what I was saying. There is absolutely no evidence to support the claims that TDD is more effective than just being a normal developer who writes tests as needed.
>This last excuse is most egregious because one rarely has time to go back and write tests
Says who? I think it is pretty absurd to invent fake problems to try to justify something. If TDD were actually useful, proponents wouldn't need to compare TDD with "don't write tests at all because obviously the only way to end up with tests is using TDD".
If you have a better design tool in your arsenal, feel free to use it, but before you slam TDD as a cult, I'd ask what is your design process and why/how is it better than TDD?
Finally, I'm not interesting in raving about design processes. I am interested in hearing about how other technical people work. What design process do you use? Why do you prefer it to TDD? How have you gone about comparing the 2?
Hyperbole is a far cry from "a slam".
>Who are "these" people?
The ones writing articles like this one.
>what studies are you referring to?
http://theruntime.com/blogs/jacob/archive/2008/01/22/tdd-pro...
>Finally, I'm not interesting in raving about design processes.
But you are the only one doing so? The rest of the paragraph that follows that sentence for example. Most people do not have a religion they call a "design process".
1. How do you determine what is a "unit" that should be covered by a test? 2. How do you determine what a given method/function's responsibilities are? 3. How do you determine where to put a given method or function? 4. How do you get feedback on if your design decisions are correct?
You've also yet to tell me what it is specifically that you don't like about TDD. I'm truly not trolling, I'm curious whenever anyone has such vitriol for a given software technique.
As for the linked article (and the underlying primary research) criticizing TDD, I had read both of those before and I think they speak to a problem with the primary research more than addressing TDD in any significant way (that's not to say you couldn't design a study that did prove TDD was harmful).
Finally, are you being ironic when you say that the original posted articles author is being cultish about TDD? The article specifically tells it's readers not to use TDD. I don't get how that is cultish.
Clearly you intended to have the nuanced view that sometimes TDD is ok and sometimes you shouldn't use it. I guess I mistakenly read the author to say that when in fact you were the one with this point of view all along. My mistake.