Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reasons to Avoid Test Driven Development

softwareandi.com

Post reply on HN
Print view View original

41–42 of 42 posts

Re: Reasons to Avoid Test Driven Development

#41

Post by lancefisher »

CJefferson wrote: post #2

This article is just irritating sarcasm. There are perfectly good reasons to avoid test-driven development. Like being part of an existing large project, where there are already too many interconnected components. Or working in complex AI algorithms, where separate testing of components is extremely painful, and lots of whole system testing is necessary anyway.

I thought it was going to be sarcasm, but clicked through anyway hoping it wasn't.

Sarcasm is annoying and often hurtful. I've tried to eliminate it from my everyday speech. Maybe that's a reason this article irks me, and I like TDD.

Re: Reasons to Avoid Test Driven Development

#42

Post by dasil003 »

tzaman wrote: post #36
lucisferre wrote: post #16

Earlier quoted context omitted.

Agreed this was completely pointless. Bottom line is not every line of code needs testing, and TDD alone does not have an impact on code quality. There is nothing I hate more than bad code covered by even worse test code. Here is a talk for anyone who is wondering why TDD doesn't make sense as a default mode: http://www.youtube.com/watch?v=LeVvj4HENOQ Bottom line is that writing TDD style unit tests won't make crap c…

Not entirely true: If you write tests, chances are you're educating yourself on how to write them. As a consequence, code gets improved - because it's almost impossible to write any kind of tests if the code is crappy. But then again, maybe that's just me :)

I think it is entirely true:

> TDD is a tool, nothing more, nothing less

Essentially TDD is just one more form of testing and/or specification. The reason it's so good is because of the properties of executable code: namely that it's fast, precise and repeatable. Human-based QA processes also have their advantages, and if you had unlimited human QA resources then the value of automated testing would be significantly (though not entirely) diminished.

But in the end, testability is ancillary, it's a second-order concern to the actual operation of the software. The ability to write a good test is secondary to the ability (and wisdom!) to choose the right architecture. In other words, a simple and correct program using some advanced techniques in, let's say Haskell, would be preferable to a kludgy Frankenstein beast of a program written in Ruby but with great test coverage over the areas of the problem domain that the programmer was aware of.

Obviously that's a straw man; automated testing is an extremely powerful technique, one which requires practice to master, and TDD shines in its ability to lift the scales from the eyes of the beginning programmer and see programming from a new perspective. However TDD, BDD et al are no silver bullet and no different from learning functional progamming, gdb, printlining, modular programming, meta programming, dynamic programming, regular expressions, or any other algorithm or technique. All just tools.

Post reply on HN