If you’re using Mechanize through Webrat though, things are a little different. The nice thing though, is that you can do this in a step definition – allowing features to be based on different browser scenarios (this is great if you’re developing across devices).

First off there are two accessors of interest in mechanize, “user_agent” and “user_agent_alias”. The former is fairly self evident and lets you define the user agent at will, the latter gives you shortcut access to a list of common user agents baked into mechanize. You can see that list in the mechanize.rb source. It contains some desktop browsers, the iPhone and the default Mechanize UA strings.

If you’re happy with the default alias list, you can just write a step definition like this:

Given /^I am using the "(.*)" browser$/ do |browser|
  webrat.adapter.mechanize.user_agent_alias = browser
end

And then you can use this in your features:

Given I am using the "iPhone" browser
When I visit the home page
Then I should see "You are using an iPhone!"

If you want to be able to specify your own UA strings, and as I said this is especially likely if you are developing cross-device applications where capabilities are important, then you can just use your own hash instead, and set “user_agent” rather than “user_agent_alias”:

Given /^I am using the "(.*)" browser$/ do |browser|
  UA_ALIASES = {
    "Nokia N95" => "Mozilla/5.0 (SymbianOS/9.2; .....",
    "Palm Pre" => "Mozilla/5.0 (webOS/1.0; ....."
  }
  webrat.adapter.mechanize.user_agent = UA_ALIASES[browser]
end

With a little tweaking you could use both the included list and, if the string from your feature isn’t there, look in a custom list too.

This gem was originally designed to work with Cucumber, and initially was intended to just validate pages against the XHTML Strict doctype that BBC pages are usually required to use. Since it uses Nokogiri for validation – against the XML Schema rather than the Doctype for what it’s worth – the testing is a) strict and b) *fast*. There are no external webservice calls, so it is fine to test all page loads within Cucumber, even testing the same URI many times over (since the bottleneck will almost certainly be your app by some margin.

I’m currently working on a post about using the gem for the BBC Web Developer blog, but I thought I’d point any interested parties at the code here and now.


When /^I am on (.+)$/ do |page_name|
webrat.adapter.mechanize.set_proxy('proxy.host.com',8080)
visit path_to(page_name)
end


I’m sure there’s a tidier way to do this, but it’s quick and it works with the following gem versions:

Cucumber 0.3.11
Webrat 0.5.3
Mechanize 0.9.3

The trick is to use JRuby and its gems, and also to install libxml2-devel

$ cd ~
$ wget http://jruby.kenai.com/downloads/1.4.0/jruby-bin-1.4.0.tar.gz
$ tar -C /usr/local/ -xzvf jruby-bin-1.4.0.tar.gz

You should now have Jruby. Add it’s bin directory to your path, presumably in your ~/.bash_profile file:
$ export PATH=$PATH:/usr/local/jruby-1.4.0/bin
$ jruby -v

Now install some mechanize requirements:
$ sudo yum install libxml2-devel libxslt-devel

If you don’t already have the “normal” ruby installed, you can get to the jruby “gem” command by just typing “gem”. If you do have ruby, or want to be absolutely sure, type the commands like this:
$ jruby -S gem install cucumber mechanize webrat

You’re good to go! You should now be able to run your features with:

$ cucumber features/