Thought Nursery

I went to Elisabeth‘s Open Source Testing Automation Tools Love In with a very clear mission: “Get SafariWatir testing my local WordPress instance the right way“, where the right way meant using a single script that would also run against IE and Firefox without modifications. I’m not sure I was a good OSTATLI participant because I spent most of my time in the corner trying to get my goal met while other people were talking about cool stuff (which is why Watir/FireWatir/SafariWatir didn’t make the list of tools; I didn’t know we were making a list). But I had a blast anyway and was able to meet my modest goal.

My starting point wasn’t quite ground zero but it was close. I used Ruby on a project for a couple of months a couple of years ago but I haven’t used it since. And I’ve never used Watir. The last time I wrote tests to drive a browser it was 2002 and I was using WinRunner.

My motivation for this project came as a side-effect of my recent change from full-time to consulting/contract work. I’ve been working out of NextSpace, a coworking operation in Santa Cruz, and that has given me a different set of colleagues than I’ve had in the past. I’m now daily rubbing shoulders with a range of interesting people, but a bunch of them churn out websites for a range of clients. The technologies vary — WordPress, Drupal, Flash, Ruby/Rails, etc — but one common factor is there seems to little in the way of automated testing, even for sites that involve a lot of custom coding. I’ve wanted to know if some of the tools from enterprise IT and product development could be applied in their context.

I was interested in using Watir for a few different reasons. One seeming motivation is that I’ve done some consulting for WatirCraft, but that’s getting things out of order: I was interested in what they’re doing before I started working with them. What really attracts me to Watir is the philosophy that they want to take maximum advantage of Ruby as a language, as opposed to having a language neutral API like Selenium. I enjoyed Ruby when I worked with it and I’d like to do more of it. I also really like the idea of Ruby as a language for testers. Testers have long done more coding than they get credit for; switching that coding to Ruby should offer more opportunities for collaboration with developers and more credit and status from the coding they were doing already.

I was also interested in doing this experiment with Ruby because Bret/WatirCraft have been working on a new WatirCraft framework, with the source available in GitHub, and one of the enabling changes in Watir was to allow browser independent scripts by using Watir::Browser.new. All the references I’ve seen to this reference IE and Firefox, but since I’m on OS X (and because I’m a bit of an Mac fanboi) anything that doesn’t work with Safari is a non-starter. I went so far as to ask for Safari support on the WatirCraft UserVoice page only to be told it was already there. Oh. Okay then…

So here’s what I actually did. I installed the very awesome MAMP, an all-in-one installer for Macs to run an Apache, MySQL and PHP stack. Next was WordPress 2.7. Ruby 1.8.7 came via the also awesome MacPorts. Then began the fun that started “sudo gem install …”:

• safariwatir
• firewatir
• rspec
• cucumber

I didn’t actually use Cucumber, but there was talk of it in the air and the examples look interesting so I gave into the peer pressure. (Maybe in a future OSTATLI…)

Honestly I struggled a bit getting started from that point, trying to run the Watir tests against SafariWatir… or even the SafariWatir tests on itself! But here the power of Twitter came in handy, with Dave Hoover stepping up from behind the SafariWatir twitter account and updating the directions for running the Watir tests in GitHub in real time. Dave likewise saved me from the rathole of the old SafariWatir tests. In the midst of my struggles I did come to appreciate GitHub. It was trivially easy for me to fork SafariWatir and send a couple of minor tweaks back to Dave. After years of taking submission to CruiseControl via patch files and working with CVS and SVN, I’m jealous!

Eventually I was able to sort our some basic RSpec syntax and some basic Watir syntax and put together this script which met my goal. If you have the default WordPress 2.7 site running on port 8080 (and you have the same admin password that I left hardcoded in the script) then this script will open Safari, log into WordPress, post a message and logout. Change Watir::Browser.default = ‘safari’ to Watir::Browser.default = ‘firefox’ (and install JSSH) and the script will run against Firefox instead. This setting is in script for connivence; if I were testing in anger I would be setting it with an environment variable from Rake as I ran the tests.

My plan for the future it to take this a step farther and try running the same tests from Celerity. My vision is a system where we run tests in Celerity for fast feedback and then run across browsers to surface compatibility issues.

I would love to do more work doing cross-browser testing with Watir (and fix some of the incompatibilities in the process). If you know of anyone with a contract for that kind of work they can contact me via The CI Guys website.