Coding Horror: Exception-Driven Development | Hacker News Reader

Coding Horror: Exception-Driven Development

codinghorror.com

28 pointsAnon8411 comments

This article is filled with pretty obvious statements:

You need to include failure reporting tools with your app and c'est tout.

I disagree, however, with the reasoning of getting rid of TDD to become a firefighter developer on the basis of exception logs. That can shoot yourself in the foot when your need to ensure system isn't broken when new features arrive.

<off-topic> Am i the only one who is tired of getting almost every coding horror post on HN? </off-topic>

Unless I suck at reading (which is possible), I don't think he's advocating people get rid of TDD.

"While there are many other valid reasons to practice TDD, as a pure bug fixing mechanism it's always seemed far too much like premature optimization for my tastes."

It also links to ELMAH, which I didn't know about, and which doesn't seem to exist for Java/Clojure.

That's news to me.

pretty typical coding horror post

misunderstands TDD, and make a correct and vital, but fairly obvious point

But he uses such a captivating picture!

http://acronyms.thefreedictionary.com/tdd TDD: Test Driven Development (programming methodology) http://en.wikipedia.org/wiki/Test-driven_development

I don't understand exactly what you're saying. He's pointing out that TDD fixes bugs that you think might be relevant, but putting your code in front of users finds real bugs. Then, you can fix those, and your software is better for it, since it addresses all the cases your user actually sees.

I'll admit we don't practice TDD where I currently work, so I might be missing something. He even says that there are many other reasons for using TDD, and his criticism here is only towards it as a bug-fixing tool. Given that, how is this not a valid critique?

TDD is not about just catching bugs. TDD is to enable you to change your mind about architecture. If you have a complete suite of unit tests, it's much easier to do major refactorings with confidence.

As far as catching bugs go, real users have no substitute. But you leverage the knowledge of real users by capturing their examples and creating automated tests from them. There's no sense in wearing out human resources by having them do the same things over and over.

agreed (kinda)

TDD has nothing to do with fixing bugs, bugs are where the program differs from its specification, TDD is about creating that specification, in a way that can be tested.

He said TDD isn't any good at fixing bugs, and the loud retort is that it isn't any good at fixing bugs. How is this misunderstanding TDD? If anything, I suggest he understands it and also understands that his readership don't understand it and he's cautioning them against misusing it.

All in all, I'd say the people who say that TDD isn't about fixing bugs are in violent agreement with Jeff.

For Rails people, there's http://hoptoadapp.com. (happy user, no affiliation)

Reply on news.ycombinator.com