Why Test Driven Development Has Snatched Much of My Time And How It Will Pay Off

OK, that's a pretty big topic for a blog post. Yet I want to get something up about the sparseness lately of interactive history resources. Which after all is the core topic of this blog.

The cheesy answer is 'go read The RSPEC Book.' While not an unreasonable approach, said book (and everything else I read for months) left me hanging.

Cucumber seemed appealing on the surface and unattractive the first step in. Controller and model tests are good for working through details, but not what I needed to get things going.

And everything online about testing seemed to be just a bit too much yesterday and not quite enough today.


Finally some kind soul on IRC (Carol N.) gently explained that Request Specs were the thing to do. Thank God! So, happily, sixty some request specs now give a smattering of assurance that the app will continue to work once changed.

Not totally. Runs still produce inconsistent results. A 60 test run will produce 3 failures, but then a 7 test run will produce 5 red lights. So something is fishy in the test setups.


Oh, and along the way we've danced with Project Sprouts, a compelling tool to bring TDD and Ruby to Flash/Actionscript... Oh, but the iPhone seems set to never display Flash in the browser, so...


All of which is more than you need to know if you're not a programmer. And less if you are. As to the Interactive History Resources, the answer is simple:

TDD is what we need to present you with more resources, present them in a better context, and make your access a more pleasant and compelling experience.