Test driven development: take a step back

When you do Ruby on Rails development for a living, Test Driven Development is a given. I would be very uncomfortable without tests, most likely I couldn’t do a job at all. So far, so good. But RoR, being the hottest web framework there is, draws a very “alpha geek” crowd. You know, people who always flock to the latest and greatest thing. You see, testing is out. Speccing is in. And I don’t like it.

Since testing is built-in, and speccing means getting extra software, and since speccing is newer and developed by other alpha geeks, speccing has the Oohh Shiny factor right now. Speccing is sexy, and testing is lame. Testing is for n00bs!

A while ago I fell squarely in the speccing camp. Har har, those fools still doing tests! The unwashed masses!

But after completing my third, actual, real-world app doing pure Rspec, I have completely lost my faith. RSpec is still a moving target and I regularly have to massage the speccing framework into behaving. Quite tellingly, just recently I had to resort to a Capistrano trick to remove spec tasks from the server. And then Rspec itself is considered to be lame by the illuminati. Shoulda is where it’s at! Another paradigm to learn. And rspec doesn’t even cover all of Test::Unit’s assertions.

Now don’t get me wrong, rspec has some very, very cool things going for it. But after doing these three actual projects, speccing still isn’t in my blood. I still have to look stuff up. I still can’t spec everything I want. When I change code around, specs fail. Chained method calls are a no-no. I could go on.

So I solemly declare that my next project is going to be good old fashioned TDD again.

Thank god the good fellows at thoughbot agree with me. Maybe we are the alpha-alpha geeks after all. Test::Unit ftw!