When I first heard about test-driven development, it not only made perfect sense, I realized it was something I had been trying to implement (without the benefit of dynamic automated tests) by had in weird-ass languages like Prograph and R. Hearing about it just made sense, though it took me some time to climb on board the languages in which it was (back then) simplest to implement.

But I never got over the ass-backwardsness of assertion-driven TDD’s workflow: the sense that every unit test is a little magic trick. “Observe, as I create this NewObject. [applause] Nothing inside, nothing outside! I assert that NewObject.inside is aValue. No? It is not? [amused laughter] But where is aValue? Ah… but watch, watch carefully as I type, and… voila! My assertion is now correct!”

Close. I understand, I understood, I had been trying to do something like that in many ways, back long long ago.

But not quite. Especially, I’ve found, for the accumulation of unwritten tests. Yes, as you move forward with traditional test-driven development you will think of other things you should do. It should check for errors. It should fail gracefully when it can’t connect to the pipe. It should be an integer, not a float. &c &c

A while back (more than a year?), I installed and worked for a while with rspec and cucumber. I had been lured to Ruby years back by Ron and Chet, but never really got too far along my path that way. This was… different.

And then, a big bunch of Python. That’s slowed down, and now with Barbara I’m coming back to Ruby (and Rails, but not so much as Merb). And BDD is there, ready for me, and greatly improved.

No, really: rspec is exactly how the smallest increment of automated test-driven unit testing should work. Cucumber is [almost] exactly the way the smallest, simplest increment of automated acceptance test-driven project management should work.

The problem? The rituals of file linking. You have a specs file; you have a features file; you have a steps file; you have your actual code; you have your helper files…. Somewhere in that mess, you have a mesh of spaghetti, all sorts of stuff referring to other stuff. And that’s confusing. A little, teeny bit disappointing, even.

Don’t get me wrong: the latest rspec/cucumber release is the next resonant “yes” in a chain of substantial improvements in the way code can be written. Because with rspec you can gracefully and communicatively catch those incidentals: “it ’should check for errors’… it ’should fail gracefully’” You can say that in rspec’s cunning framework; you can let the customer say what it is they want, with Cucumber.