Inspired by a recent Railscast on Capybara, I decided to satisfy my holiday coding urges by looking into how Capybara might help us automate more testing at Podio. We are lucky enough to have a full time resource doing quality assurance, and we have often talked about how something like Selenium might help her automate a number of “sanity checks” that we could run before deployments. When I realized how well Capybara work with Selenium’s web driver, I had to investigate a bit more.

Podio is currently a mix of PHP and Rails (talking to a Python-driven API), and these automated tests of course had to work independently of whether a certain page was in PHP or Rails. Also it would be nice if our QA didn’t have to have the sites running locally to run the tests. These things ruled out running Capybara inside the Rails application, so I opted for making a seperate, Ruby-only test-suite for automated QA running against our staging server. There is a ton of challenges in this that I haven’t fully solved yet, most importantly how to manage test data on a separate server. This article only outlines how to get a simple Ruby application (without Rails) up and running that can test a remote site.

First step is to install the bundler gem, create a Gemfile in the root of the application and run the bundle command:

The gotcha here is that the “trunk” version of the Capybara gem on Github should referenced in the gemfile for compatibility with RSpec 2.

Second step is to setup a spec_helper.rb file. I created a spec folder in my application directory and put it there:

I have some things in my spec helper you might not want: In line 6 I require all files in spec/factories. This is where I put method for generating test data. This has to be done “by hand” through Capybara as I am testing against a remote server. In line 10 I configure Capybara to save page snapshots in a directory called snapsshots so I can git ignore the files Capybara generates when using the save_and_open_page method. In lines 20-27 I configure RSpec to open a snapshot of the current page if an exception is raised during a test.

Lastly I place the actual specs within the spec/requests directory, following the RSpec naming conventions for this type of tests:

One important gotcha here is that the describe block must be followed by the :type => :request option to trigger Capybara. It’s only within Rails that this type is automatically set for all specs in the requests directory.

What I have now is still very far from the holy grail of automated testing from a user perspective, but it feels like a step in the right direction. If we decide to pursue a setup like this on Podio I’ll most likely do another blog to follow this one up. If not – and there unfortunately many things making tests like these very brittle and hard to maintain – the quest for more and better automated tests continues :)

Bookmark and Share