Some asked "Would Schizoid have been better/faster without TDD?" In other words: "Was it a win?" That's what I was trying to say in the last post: pretty sure it's a win. Higher quality product (in the fewer bugs sense) developed faster (because a quality / stop-the-line mentality -> long term speed). But it's not a clear, obvious, "how did we ever live without this?" win - and although I feel like it's a win, maybe I'm wrong - impossible to prove, one way or the other, without a change-one-variable, control-group experiment. (Two identical teams develop Schizoid - one uses TDD, the other doesn't.)
The "safety net" -> "more courage" thing is definitely true. (And using C# is also a good safety net!) We're quite fearless about making changes - quite a difference from our Spider-Man days, where we'd lock down days before a big milestone and only allow people to check in one at a time.
Jeff mentioned monkey & integration testing. Soak tests, monkey tests, and end-to-end builds ARE clear, obvious, "how did we ever live without this" wins. Maybe not a silver bullet, but definitely a copper one, a best practice you can't afford not to do. Which is why most people already do it. If anyone's considering TDD who doesn't do soak tests or have an automated build system in place - get your soak tests and build system going first!
Here's an old article I wrote on how we used to do it. The key takeaway is that "daily builds" are so five years ago! It's all about the "end-to-end" build these days.
We do end-to-end builds with Schizoid, using Parabuild on our build server (took under a day for us to get it up and running with Parabuild - quite a difference from the weeks put into the Spider-Man 2 build scripts), and it runs NUnit rather than running the actual game. We haven't been 100% disciplined about it - the build server broke down and it took us a few weeks to replace it, at one point. And we run soak tests manually - sometimes with the AI playing the game and sometimes with external random monkey.