In addition to the comments on this post, there's some more discussion on Jacob's cross-post:
http://scruffylookingcatherder.com/archive/2008/01/31/tdd-or-pout.aspx

<shamelessSelfPromotion>
including comments on my attempted response:
http://davesquared.blogspot.com/2008/02/brief-look-at-logic-of-tdd.html
</shamelessSelfPromotion>

< Apologies in advance for the two-parter >

Beliefs may take one of two forms:
1. faith in the unprovable or
2. assumptions of the verifiable but with no effort made to verify.

At http://scruffylookingcatherder.com/archive/2008/01/31/tdd-or-pout.aspx Jacob wrote:
"Asking if I have any experience with TDD implies that without that experience I'm not competent to evaluate TDD tenets and make reasonable judgements about them. I reject that implication outright. I've said in prior posts that I'm reluctant to "gain the experience" before I've seen a reason to believe I'll receive benefit from it. That case hasn't been made to my satisfaction yet."

At http://www.theruntime.com/blogs/jacob/archive/2008/01/31/tdd-or-pout.aspx Jacob wrote:
"I have not, as yet, used TDD. You're right, I'm not convinced enough to give it a go."

I would personally characterize many of your recent posts about TDD as reasonable attempts to point out that the practice of TDD may be too often subject to the first definition of "belief" above. In finding that this be true in a given situation, I would absolutely encourage anyone and everyone to point this out in an effort to educate: simple beliefs shouldn't be a part of methodology selection--facts and experience should.

However, I personally think you may be guilty of the 2nd definition yourself. You freely admit to never having used TDD. You are absolutely entitled to your opinion, but how seriously should I take it when between the two of us, I'm the only one who has tried TDD (and probably like you, also POUT, waterfall, various iterative models, various hybrids and "none of the above") on corporate projects and saw the results for myself? I prefer TDD when I have my druthers and a willing team, but I often settle for POUT, and I'm currently being paid to do waterfall with no structured POUT responsibilities expected of me at all.

Honestly, I wish I *could* "couch [my] arguments in the assumption that [you are] already POUTing, that [your] POUTing already delivers substantial benefit, and that adopting TDD is a non-trivial training and practice burden", but the reality is that the people in my professional software development practice who are most aggressively against the idea of TDD are those who don't even POUT in the first place--and they give similar reasons: non-trivial training and practice burden. I don't think you'd want me to assume they are just so good at coding that they already deliver a substantial benefit w/o any unit testing at all. So why do you want me to rebaseline my assumptions when it comes to the difference between POUT and TDD? Please couch your arguments in the assumption that I don't agree with the reasons you already suggested in "TDD or POUT". ;)

My take on Test-First design vs. TDD's Test-First-ALWAYS design:

http://www.dotnetkicks.com/unittesting/Test_Supported_Development_TSD_is_not_Test_Driven_Development_TDD