I like automated tests when they are low hanging fruit. Most often though, I'll settle for specs that are detailed enough to tell how to operate a feature, rather than just a hand-wave. I'm not too happy when coworkers commit code and don't bother to run it at all :-(

See the comment somebody made elsewhere about "money driven development". The cost-benefit ratio has to make sense.

TDD has some challenges, but it addresses the critical need of having solid unit tests for code that allow projects to be modified and used by diverse sets of programmers who aren't going to reach out and ask you if their change broke your code.

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."

>but it addresses the critical need of having solid unit 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".

TDD is a design tool nothing more. It happens to be a design tool that creates unit tests as a nice side benefit.

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?

I am not slamming it, it is a cult. Read what he wrote, these people literally think you either do TDD, or you are wrong. Despite all the actual testing of TDD having found it offers no benefits at all.

A) Using the term "cult" is almost certainly a slam. B) Who are "these" people? I am certainly a fan of TDD but I know that there are lots of other processes that work. I know lots of other people that feel like me. C) I would love to see what testing has indicated about TDD, what studies are you referring to?

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?

>Using the term "cult" is almost certainly a slam

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".

You keep using religious "hyperbole" and it is making it hard for me to understand your perspective. So let me just ask a couple of direct questions that are easily answered using TDD.

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.

What are you reading? Because it is pretty clearly not what I wrote. How is "I wish TDD advocates would stop equating unit testing with TDD" vitriol? Dismissing the only actual evidence because it doesn't fit your beliefs is not reasonable. TDD advocates are the one making claims. Nobody said TDD is harmful, just that it has no benefits and that TDD does not equal unit testing. As for not thinking the article author is cultish, try reading the first paragraph. It is literally "TDD is everything, all hail TDD, TDD solves all problems" and is all completely baseless.

I'm sorry that I read the assertions that you should always skip TDD and that it's proponents are all members of a wacky cult as calling TDD harmful.

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.

I'm not sure how this is still unclear. Something having no benefit does not mean it is harmful. My pointing out that TDD has no benefits does not imply that I think it is harmful.

Citation needed.