> I think the "test-first" approach has more focus on ensuring you don't write any production-code until you have formalized the requirements for that piece of

> I think the "test-first" approach has more focus on ensuring you don't write any production-code until you have formalized the requirements for that piece of business-logic. In fact the SWEBOK 3.0 section on test-driven design mentions this. It was first proposed in extreme programming as an alternative to more formal specification methods. > I can definitely see the appeal, but I'll be the first to admit I don't go the full mile myself, always. And that's I guess what this blog-post is all about. Be critical about how you apply well-meant advice. As banal as such advice is if that is as far as the article went I'd be fine with that. However the argument was weakened when the author eschewed unit tests out of, what appears to be, ignorance. I don't always write tests first either... when I'm prototyping I'll usually try a few approaches first. However I generally throw out that code once I find a tack I want to take and begin specifying the interfaces, constrains, and invariants through tests. In higher-level languages with sound type systems I generally rely on properties of the type system and compiler in lieu of tests I'd write in a more dynamic environment. It's just a matter of preference that I tend to think more before I write code and write tests first.