This post originated from an RSS feed registered with Ruby Buzz by Ryan Davis. Original Post: Alas... not speaking at rubyconf 2006 Feed Title: Polishing Ruby Feed URL: http://blog.zenspider.com/index.rdf Feed Description: Musings on Ruby and the Ruby Community... Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Ryan Davis Latest Posts From Polishing Ruby

I was not chosen for rubyconf 2006. Here was my final and submitted proposal:

Summary

There is a subtle difference between Plain Automated Testing and Test Driven Design. Whether it is called "Test First", "Test Driven Design", or "Extreme Testing" there is one thing that is true: TDD is a expands your mind when it is truly done. I hope to share that experience. I plan on taking those who know TDD and push them further while still being accessible to those to don't know automated testing at all.

Details

There is a huge difference between your average software project and one that routinely does testing in the form of automated unit and system tests. Automated testing is about reducing or removing fear and pain. Fear of breaking things and the pain of maintenance. That difference is similar to climbing a sheer face of a cliff without rope and harness compared to the confidence you gain knowing that you are climbing with rope and belaying partner.

But this talk is not about that.

The difference between plain 'ole automated tests and Test Driven Design (TDD) is much more subtle. It is like the addition of a pair of good climbing shoes and some chalk. It doesn't decrease the fear so much as it gives you focus and clarity, making you more effective. It may seem counterintuitive, but TDD doesn't limit you, it expands your options as it expands your mind.

Your mind starts to clear as you take on TDD and start to shed years of bad habits like overly complicated logic, featuritis, and delving too deep or too fast. You become bolder knowing your tests will catch you when you fall. Eventually your consciousness expands to fill this void as the clutter fades away. Your focus changes and the signal to noise ratio improves as you simplify your design, your code, and your thinking. As a result, you start to look at the whole game differently.

I hope to expand some minds with this talk by incorporating the TDD foundation, add a sprinkling of XP practices, mix in the ZenTest toolset, throw in some Weinberg, and of course, share a drink of some electric kool-aid. :)

By the end of the talk, the audience should have a good grasp on:

• The difference between writing tests and test driven design.
• The TDD life-cycle.
• YAGNI or "You ain't gonna need it".
• "Do the simplest thing that could possibly work".
• How to properly optimize your code and how not to waste your time.