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

11 pointsby jcwilliams15 anni fa4 comments

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 do understand where the value of it comes from.

I just think it's a slow and bureaucratic process where the same value can be obtained in better ways.

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.

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.

And I have 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).

Am I alone in thinking this?

4 comments

jcwilliams15 anni fa

Note to self: search archives before posting. Just found this: http://news.ycombinator.com/item?id=2240595

manuscreationis15 anni fa

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

astrodust15 anni fa

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.

herdrick15 anni fa

Of course not. Most startups avoid TDD.

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