When I first started poking around the codebase a few months ago, they’d just started writing a few cucumber selenium integration tests – which of course I want to encourage! – but they weren’t running them on their continuous integration box. And if you aren’t running them on CI, you can’t really call them tests…

It’s not that the developers were lazy; it’s just that Diaspora’s CI box is an ubuntu server instance that doesn’t even have xwindows. There’s no way to attach a display, and without a display, a browser won’t run. So how can you run selenium features that have to actually open a browser window and click on stuff?

I’m glad you asked!

You set up a virtual framebuffer – essentially a simulated display – and run your features in there. Here’s how I got this going.

Step 1: Install Crap

Yeah, you need xwindows, and a bunch of other stuff. I’m not a frequent linux user, so I was surprised that a lot of these commands appeared to fail, with extremely lengthy output about how such-and-such dependency could not be installed, or compiled, or resolved, or kafloozled, or whatever. But then when I ran the programs that supposedly weren’t installed, they worked fine. …thanks, ubuntu?

sudo aptitude install xubuntu-desktop
sudo aptitude install exaile
sudo aptitude install gconf2
sudo aptitude install xvfb
sudo aptitude install firefox

Step 2: Verify Your Virtual Framebuffer

I like the phrase “virtual framebuffer.” It’s very computer science, and using it makes me feel smart. But really, it’s just a display that gets rendered in memory, but not output to any monitor. Programs that require the ability to create windows, such as Firefox, need a display to run in – but they’ll take any old display. If you give Firefox a virtual framebuffer, it’s perfectly happy and treats it like any other display, even though no one can see it.

So let’s verify we have everything set up to run one. This magic incantation starts one on display port :99.

 Xvfb :99 -ac -screen 0 1024x768x16

In another shell, run this one, which opens Firefox to example.org inside the virtual display you’re running in the original shell.

DISPLAY=:99.0 firefox http://example.org

Firefox is now open to example.org, the world’s most boring webpage. Really! Let’s prove it by taking a screenshot in a third shell.

xwd -root -display :99.0 -out xwdout

Your screenshot is now in a file called xwdout. Sadly, this is not an image format that normal image viewers can see, so let’s convert it to a jpeg.

convert xwdout screenshot.jpg

Using your favorite sftp program, retrieve screenshot.jpg and have a look at it. It should look something like this:

That boxy UI, those icons from 1995...it could only be linux.

Ta-da! You have evidence of this so-called “virtual” framebuffer. Now all we have to do is set it up so to start before we run the tests, and stop once the tests are done.

Step 3: Adventures in Shell Scripting

This goes in your /etc/init.d, and will give you ULTIMATE POWER, if ultimate means you can start and stop a virtual framebuffer on display port :99.

Now you just need a rake task that starts the display, passes the port info to the tests, and then stops it.

And just in case you have to get this running with rvm, here’s the shell script that cc.rb calls to kick off a Diaspora build on ruby 1.8.7.

I’ve had to set this up twice, now, but there are a lot of moving parts. If you try this and notice something I forgot, please let me know.

Enjoy your headless cucumbers…

(I wonder what kind of google search results that will get me.)

Part of that was exhaustion – between the conference on Friday and Saturday, the hackathon on Sunday, and, uh, working the five days after that, it’s kind of been full-speed until today. Part of it, though, was also that the second day wasn’t as positive an experience for me. It’s taken me some time to collect my thoughts.

Rather than touching on every presentation, I just want to note a few of them that I really liked.

First, there was Jacqui Maher’s presentation on the work she’s been doing with Baobab in Malawi. Back in 2000, I spent three months in Ghana helping a software company in Accra go from Delphi/C++/Windows to an open source stack based on linux and Java. It was an incredible experience, but since then I haven’t been able to reconcile my desire to help with my actual skills. I mean, the Peace Corps is awesome and good for you if you want to do it, but they’d have had me teaching math or something. I want to code.

So I’m thankful Jacqui came and talked about this project. I don’t think any of my code has ever had a measurable life-saving effect. Perhaps that should change.

The Webrat talk from Bryan Helmkamp was also really interesting. At Looksmart we have a huge Selenium test suite, and I’m not at all happy with it. I will likely gravitate towards talks on different methods of acceptance testing at Railsconf – Webrat looks interesting. It doesn’t actually fire up a browser, so it’s faster, and you can drop down into Selenium when you need to test Javascript.

By the end of the day, my brain was full. People tell me the last talk was great, but I have very little memory of it. Hopefully the justin.tv folks who were filming the talks will have it up soon so I can see it when I’m in a state to appreciate it.