RSpec and Recurring::Schedule

After a long week agonizing over a scheduling library, and then specing it out rather quickly, I’ve got some work I’m pretty happy with.

As a contrast to Test::Unit, I like the way RSpec spreads my attention around the codebase while I concentrate on implementing specific behaviours. In Test::Unit, I tend to write tests around the private methods of the object under test.

So far I haven’t involved RSpec in tests of object interactions, so I haven’t had a chance to use the mocking features. I use Mocha for Rails sometimes, so I’m excited to see how it feels under spec.

The nicest thing about the writing process was thinking of my library (just one class, Recurring::Schedule, for now) through the lens of it’s public API. A few months ago, I made an attempt at this library, using Test::Unit, and results, while they functioned as prototype for weeks while we worked elsewhere, were nigh unrefactorable. Writing from scratch with RSpec gave me a faster library, in less time, with less code, while worrying less about code duplication.

My previous TDD attempt had all these fancy metaprogramming methods and whatnot, which I completely dropped in the rewrite. I think that’s thanks to the way RSpec spreads your efforts around the codebase as you iterate over specs and code. With Test::Unit, I usually think really hard about what a method has to do, and then write it test first, and it comes out looking beautiful, with tightly woven ruby knots.

With RSpec, I don’t have to think, at least not hard, and all at once. I build up behaviour, a little at a time, filling in the methods when I need to.