

Am I the only one that thinks TDD is really antithetical to agile development? - jcwilliams

I've read a lot about TDD including a few good tutorials, and I've watched a few screencasts, and I tried it out a couple times (once last year and again more recently). And I really do "get it". I <i>do</i> understand where the value of it comes from.<p>I just think it's a slow and bureaucratic process where the same value can be obtained in better ways.<p>I saw this definition of TDD online: "one way to think through your requirements or design before your write your functional code". That's one good characterization of TDD, and where most of its true value comes from, but there are processes to "think through your requirements or design" that are both much quicker and more effective.<p>And like all design methods, TDD only works well if you're doing it right. If seen it postulated that good TDD forces (or highly encourages) you to write good code. But that's almost a tautology. If you're good enough to do TDD well, you're good enough to code without TDD. It doesn't help you any more than you help yourself.<p>And I <i>have</i> seen a whole lot of bad TDD out in the wild, where the tests offer no value or nearly no value because they are badly designed. In these cases it just adds boring busywork and a false sense of security to the coder (which might lead to even worse code than if there were no "tests" at all).<p>Am I alone in thinking this?
======
jcwilliams
Note to self: search archives _before_ posting. Just found this:
<http://news.ycombinator.com/item?id=2240595>

------
manuscreationis
I've seen a few examples of TDD that, like you say, offer a very clear benefit
for writing your logic and making sure you're covering your bases. However,
they feel as though you're going around your ass to get to your elbow.

I'm still a very firm believer that you should be created your code base with
being able to write proper testing in mind (separation of concerns, IOC/DI,
etc), however I would be lying if I said that pure, evangelist style TDD was
my cup of tea.

But TDD can be one of those religious style debates that I typically like to
avoid...

------
astrodust
If TDD helps you achieve your goals faster, which in some cases it can, then
use a TDD-based approach. If it's holding you up, making what should be a
throw-away prototype take significantly longer to implement, then abandon it,
but be aware of the inherent risks.

Obsessive TDD doesn't help anyone. You have all these "test cases" that give
you false confidence, and worse, take forever to maintain as you try and
improve your product. You can literally test something to death this way.

------
herdrick
Of course not. Most startups avoid TDD.

More generally, trust your gut, especially when people start talking about
Methodologies. Your instincts are good.

