Panasonic Youth rob sanheim writes about software, business, ruby, music, stuff and things

Why I use test/spec over rspec

…the worst thing that can happen to a code base is size. — Steve Yegge

(Lines of code counted with sloccount, adding up only results from the lib and test (or spec) directories for each of the latest gems.)

This sounds like the old discussion about “DRY your specs”.

I’ve found specs be more clean and understandable for a new comer than Test::Unit::TestCase.

Anyway, is a matter of personal taste than anything else, the most important thing is “getting things done” :-)

Out of curiosity, why lines of code is important to you as a consumer?

Should you also point out the LOC from test/unit which test/spec is built on? And also that RSpec has builtin mocking and story frameworks?

Sammy: I’m a developer, not a consumer. My test (or spec) library is one of the most important tools I use. I need to be able to read it easily, dive into the code, and hack it as need be. Small size means I can hold it in my head that much easier, and change it or improve as I work with it.

Geof: I would argue that *normally* I only have to go one abstraction deep, so I typically don’t need to understand test/unit in order to hack test/spec.

I really dislike the fact that rspec includes yet another mocking framework. Why not mocha? (Yes, I know you can pick the one you want, but rspec’s generator uses its builtin mock framework, therefore making it hard to switch)

The story framework did look very cool from the demo I saw at RubyConf last year, and I would love to try and use in isolation when its more stable.