SafariWatir Nuisances Comments

The place where I work (RideCharge) is a Rails shop. As such, we’ve embraced numerous Ruby technologies, including several ActiveRecord plugins, test frameworks, and other components used at various points in the stack. I deal with a lot of view-side and presentational stuff, including having embraced Sass for stylesheets (I even use them in some non-Rails/Ruby projects via CLI), making use of AssetPackager and so on.

One thing RideCharge has used, but which I’ve only recently expressed interest in, is Watir. Watir is a cool testing toolkit that allows you to control and get feedback from various Web browsers using Ruby. You can use it, or variations of it, with IE (the original Watir was IE-only) Firefox, Safari, or even Flash using the various variations. I’ve only spent enough time with it to get it installed and tinker a bit, so this post only deals with real in-the-field experience. As such, I’ve only played with the FireWatir and SafariWatir variations.

One thing I’ve noticed already are some nuisances in SafariWatir and FireWatir, and perhaps Watir in general in some cases:

  • SafariWatir’s goto method requires the protocol as part of the URL whereas FireWatir does not. This is a minor complaint.
  • Links in SafariWatir appear to have no href or url property (among others), despite this table showing that they should.
  • SafariWatir has no url to determine the current page.
  • No support for CSS selectors that I’m aware. This could be brought in from one of at least two Ruby projects (Hpricot or Nokogiri). XPath is a bore.
  • Confusingly it only selects the first matching element if multiple elements match. There’s no way to verify the # of elements, etc. Selecting a different matching element is accomplished through the :index parameter.
  • Having a different “selector” method for almost every element type seems strange, but perhaps this is just bias from having used JavaScript selector engines so much.
  • Having the browser “click” a link where JavaScript is supposed to intercept the click fails to trigger the JavaScript, or may simply have no effect (in one case in SafariWatir).
  • No convenient “click the back button” method. This would be useful for testing state-saving in Ajax-focused applications where browser history is an issue.


  1. Posted March 6, 2009 at 6:05 am | Permalink

    If you build the gem from the github source, there’s now a method to get the current URL.

    @browser = Watir::Safari.new
    @browser.goto “http://caius.name/”
    @browser.url #=> “http://caius.name/”


  2. Posted March 10, 2009 at 1:34 pm | Permalink

    Very cool stuff, Caius. Thanks for sharing! Hopefully it’ll be available in the gem across all platforms by the time I get round to implementing new tests across more browsers! The team here uses several platforms across dev environs and production both, and I know they won’t go for building it on every single one.

    Of course, it’d be nice if one could run identical calls against all of the Watir derivatives. That way we could abstract the whole calling of multiple browser objects’ methods in the first place! I like to think some day they’ll work under a unified spec… with CSS selectors and collections returned by selectors!

  3. Yu
    Posted March 23, 2009 at 5:11 pm | Permalink

    This is cool staff, thanks!

Post a Comment

Your email is never published nor shared. Required fields are marked *