🕷 zenspider.com

by ryan davis

Looking for the Ruby Quickref?

RubyConf 2006 Proposal (draft): Electric Kool-aid Acid Testing or Drinking the Kool-aid

Published 2006-06-28 @ 23:43

Tagged ruby, planning

REMEMBER: Proposals are due 6/30!


There is a subtle difference between Just Testing and Test Driven Design. Whether it is called “Test First”, “Test Driven Design”, or “Extreme Testing” there is one thing that is true: it is a mind-bender when it is truly done. I hope to share that mind-bender. I plan on taking those who know TDD and push them further while still being accessible to those to don’t know testing at all.


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 of climbing with with rope and belaying partner. But this talk is not about that.

[ maybe switch over to a more hippie-themed analogy :) ]

The difference between plain ‘ole automated tests (POAT?) and Test Driven Design (TDD) is subtle. It is the addition of a pair of good climbing shoes and some chalk. It doesn’t decrease the fear so much as it simply makes you more effective. Whether it is called “Test First”, “Test Driven Design”, or “Extreme Testing” there is one thing that is true: it is a mind-bender when it is truly done and it is very effective.

One of the reasons that TDD is a mind-bender is due to the changes that you brain goes through when you start to incorporate the practices of TDD and as a necessary consequence incorporate XP’s tenants of “You ain’t gonna need it” and “Do the simplest thing that could possibly work” into your daily process and eventually your way of thinking. As you start to think in TDD your focus changes. The signal to noise ratio changes 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 warp some minds with this talk by incorporating the TDD foundation, add a sprinkling of XP practices, mix in the ZenTest toolset, throw in some Weinburg, and of course, a take 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.


Ryan Davis has been using Ruby since 2000 and is a founding member of the Seattle Ruby Brigade, the ass-kickingest ruby brigade (per-capita). He has worked on and released coco/ruby, ParseTree, ruby2c, RubyInline, ZenHacks, ZenTest, and ZenWeb. He has not yet released BFTS, metaruby, or zero2rails but they are coming out RSN™. His presentation at RubyConf 2005 on ZenHacks was very pretty.

Whatcha think? Ideas? Glaring mistakes?