Beyond Testing

Testing appears to be an extremely popular practice in the Ruby community. At the past few RubyConf's there have been a handful of sessions where people are introducing new testing libraries as well as sharing there experiences around improving the performance and quality of test suites. I find it fascinating because in my professional experience developers seem likely to delegate testing tasks to others (BA, QA, PM, etc...) rather than adopt testing themselves. I have to say that for the most part the respectable part of the Ruby community really embraces testing or at least tries.
There are however many people out there who don't like it and in fact malign the technique of TDD. I recently watched a keynote presentation, by a person I respect and admire, where he likened TDD to driving in a car along a highway bumping into the guard rails the entire time to help you get to your destination. It probably one of the most absurd analogies I have ever heard in software engineering and it is nothing at all what TDD is about.
The single greatest benefit that I get from TDD is how it helps me break down unmanageable complex problems into small simple problems. It helps me see problems with design and allows me to gain confidence in my ability to improve the design when I need to. The absolute worse feeling in the world that you may experience as a programmer is fear.
Fear is a "vital response to physical and emotional danger".  It is considered vital because without it, there would be no way we could, "protect ourselves from legitimate threats". However, in software engineering we have a tendency to motivate ourselves with fear all of the time. We use fear to pressure ourselves to meet "deadlines". The fear brought on by uncertainty when you are faced with an unfamiliar piece of code. One that looks so complex and so enormous that it is impossible to reason about all of the little nuances, workarounds, mistakes, performance tweaks, etc... Fear is what makes people decide they are going to leave legacy code alone and find or create a workaround.
Before I learned about TDD, I would have never touched someone else's code. I would have never used scratch refactoring to gain a better understanding of what it was trying to do. I would have over-designed the code making it impossible for people to do something simple. I would have built an API that fit my design instead of the most suitable for the client that was trying to use it. It would have taken me twice as long to complete a task in a legacy system!

Do you want to work in Fear? I know I don't.

Update:
Take a look at this article by Jim Shore to learn about what a good test suite should look like: http://jamesshore.com/Blog/What-Does-a-Good-Test-Suite-Look-Like.html