Sorry in advance. This is a rambling post, of mostly my own notes from the weekend messing with a bunch of new-to-me technology surrounding Ruby development.
Intro to Serrano
Serrano is the name of a project I originally started when Rails first came out. (Really. There wasn’t even a Rails mailing list back then and when I requested one, DHH responded that he wanted to keep things in the IRC channel. Unfortunately, I couldn’t access IRC from work without breaking policy, which is a real career-limiting move in a security company.) Anyway, Serrano is a walled garden community site that my friends and I use daily as a means of communicating, but it was also a project I could use to learn Ruby and Rails.
I haven’t deployed a new update to Serrano in a couple of years, and let’s just say that the code isn’t pretty, although it’s been really stable. It was written by a Ruby newbie back when most of today’s Rails idioms didn’t exist, and updated to some new techniques a few times since then, usually when I wanted to play with a new Rails release.
Now I want to add some features and update Serrano to the latest Rails (2.3.4) after some time away, but it’s kind of hard. The tests I did have weren’t complete, and some are completely broken. I don’t know what the hell I’m doing at the moment, having not paid attention in awhile, so I need a safety net before I go breaking shit.
So I thought I’d take the chance to bite off some testing frameworks that have been on my radar, but I haven’t taken the time to learn how to use. Serrano is going to be a good test project again, as I intend to use this stack of testing tools to cover it well enough to aggressively refactor it into good health using the more modern techniques that have emerged since I stopped developing it.
Rspec was all the rage at RubyConf and RailsConf a couple of years back, and I even wrote a few specs for Serrano that I’d put in while playing with it. Rspec is a BDD (behavior driven development) tool that helps one test the behavior of code. I got the specs I’d written back up and running pretty quickly (along with the existing Test::Unit tests I’d written way back when) and got them all passing. It looks like Rspec has come a long way since 2006 or so when I’d played with it, so I looked around for resources on it.
The Pragmatic Programmers have The Rspec Book in beta and I’m a fan of their books, so I plunked down the credit card to get the PDF to learn from. Turns out there is a whole stack of testing frameworks out there now, and this book is about a lot more than just Rspec. Seems like a lot of stuff to learn, but I’ve got a jones to get this project healthy, so I might as well bite it off.
Another layer of this stack of testing tools is called Webrat. Webrat is a Ruby API to simulate user behavior in a web-based app without having to script a browser. Seems like a good goal, so I installed the gem. Or I thought I did.
Turns out I kept having trouble installing Webrat. I’ve been using the new beta of JetBrains’ Ruby IDE RubyMine over the weekend. (As you can tell, I’m all about trying out the latest shiznit in Ruby-land right now. Maybe it’s just to get comfy with the new stuff prior to RubyConf.) RubyMine’s gem attaching feature kept looking like it was installing it, but it failed. I tried from the command line and got this:
ld: in /opt/local/lib/libz.1.dylib, file is not of required architecture collect2: ld returned 1 exit status make: *** [nokogiri.bundle] Error 1
Nokogiri is a Ruby library for XML which Webrat depends on, and I got the same error when trying to manually install the Nokogiri gem. The libxml2 installation on my machine needed to be recompiled for 64-bit under Snow Leopard. This was fixed by installing the Snow Leopard version of MacPorts, followed by libxml2:
sudo port install libxml2
After that, the Webrat gem installed fine.
Misc. note about RubyMine 2.0 Beta: You can turn off the the (extremely annoying, IMO) spell check that tries to check the spelling of all your variable and method names, by going to Settings -> Intentions and unchecking “Spelling”. I didn’t think of the spell check as an intention, but I guess that’s how it’s implemented.
Last up (I hope) is Cucumber, which is a way to specify acceptance tests in plain English, backed by small bits of Ruby to make the statements executable. Sounds fancy–maybe too fancy if the faint sound of alarms going off in my head are to be believed. We’ll see how this goes. There are a set of basic acceptance tests I run through manually before deploying a new Serrano build, and I hope to get those running soon with Cucumber. (It’s true that I haven’t released a new build of Serrano in a long time, but I use Serrano all the time so I have the tests of critical features down pat.)
RubyMine has built-in support for Rspec and Cucumber, although I have a slight problem running Cucumber scenarios from the built-in scenario runner, so I’ve been using the shell for that. I posted a query to JetBrains about it. I have a feeling I’m using a newer version of Cucumber than they developed against.
Anyway, I’ve got my development environment all set up and it seems to be working. I have to admit to being a bit skeptical about having such a deep stack of apparently quick-moving technology targets at the core of my testing, but I’m willing to keep an open mind. RubyMine looks to be a winner, although it does wear its “beta” status proudly with a few bugs.
Just to make sure that I have enough new stuff that I’m working with, I moved the project from using Subversion to my GitHub account awhile back (although it’s a private repo since the code is in no shape for public release at this point), so I’ll get to sharpen my Git chops and exercise RubyMine’s Git integration. That means updating the Capistrano recipe I use to deploy Serrano to production, since it works with my SVN repo. Whew! Hopefully I haven’t bitten off so much that I can’t get it done. We’ll see soon enough….