Skip to main content

Watir is What You Use Instead When Local Conditions Make Automated Browser Testing Otherwise Difficult.


I spent last weekend in Toronto talking to Titus Fortner, Jeff "Cheezy" Morgan, Bret Pettichord, and a number of other experts involved with the Watir project. There are a few things you should know:

The primary audience and target user group for Watir is people who use programming languages other than Ruby, and also people who do little or no programming at all. Let's say that again:

The most important audience for Watir is not Ruby programmers 


Let's talk about "local conditions":

it may be that the language in which you work does not support Selenium


I have been involved with Watir since the very beginning, but I started using modern Watir with the Wikimedia Foundation to test Wikipedia software. The main language of Wikipedia is PHP, in which Selenium is not fully supported, and in which automated testing in general is difficult. Watir/Ruby was a great choice to do browser testing.  At the time we started the project, there were no selenium bindings for Javascript. Now that Selenium is fully supported in Node.js/webdriver.io, I understand that WMF is porting the Watir-based tests in 20+  repositories to Node/webdriver.io. It is very exciting.

Today I use Watir at Salesforce.org, the philanthropic arm of the much larger company Salesforce.com. Salesforce has its own proprietary programming language APEX, which does not have Selenium bindings and never will. Watir is the best choice to do automated browser testing in this environment.

it may be that even if your language supports Selenium, automated browser testing is still really hard

Selenium is fully supported in C#, but many Windows organizations do not use C#. Even when they do, the amount of scaffolding required for robust browser testing can be daunting. Creating an assertion framework, a logging structure, a Page Object  model, a test runner, all of these take significant investment. The Watir project allows you to short-circuit all that work.

Java and Python are in a similar situation. Watir and Ruby provide an off-the-shelf answer that is remarkably  well-documented, with a proven history of excellent design and implementation decisions as well as an active and polite user community. (Watir as a concept is actually older than Selenium!)

it may be that the browser test automation staff do not have access to the feature code

Certainly this is an anti-pattern, but it is sometimes the case that the people who need to do browser test automation are not in regular contact with the people creating the code that needs testing.

Two Paths for Watir


Right now today there are two approaches to using Watir, each with their own design philosophy, each with their own
(overlapping) sets of tools.

Simple, straightforward, and easy; but powerful

The first approach is exemplified by the project at watir_install, that I will call Team Titus. Team Titus wants to provide a single installation that yields an instantly usable Watir testing instance with no configuration, with examples in place for  anyone to follow. Regardless of what programming language you find most comfortable, Team Titus wants to provide the most  readable, understandable framework possible.

The second approach is exemplified by the project at page-object, that I will call Team Cheezy. Team Cheezy wants to provide the most powerful application of Watir for browser testing possible. Team Cheezy gives you a framework that needs to be tweaked a little to work, and has more layers requiring understanding. To understand the internals for Team Cheezy you need to know something about how Ruby works.

You should know that the barriers to entry for Team Cheezy were already low; Team Titus wants to make them even lower, but at the cost of some power in the framework.

Note that these approaches are not incompatible. They do not compete, they cooperate. Bits of each framework can be switched in and out.

Me, I started with Team Cheezy about six years ago and I'm sticking with it. I need that power. However, my heart is with Team Titus, and I intend to contribute as that project grows.


Choosing between Team Titus and Team Cheezy



Team Titus (watir_install) Team Cheezy (page-object)
Don't care about Cucumber Want Cucumber
Need easy install Willing to tweak some directories and settings
Only encounter standard HTML and DOM Needs to address non-standard page elements
Probably don't need to scale across multiple repos Needs to work across multiple repos
Want simple internal code to analyze Willing to learn some Ruby magic for internals


I went to Toronto to talk these people because I saw changes happening and I need to know the context of those changes. I
learned what I needed to know:

  • Everyone agrees that the primary audience and most important users for Watir are people who need to do automated browser testing BUT who are not primarily Ruby programmers.
  • We need to provide a framework that works for everyone upon installing it.
  • We need to provide power to people who need power.
  • We need to make it easy to start, but also easy to improve.



Appendix: Why not target Ruby programmers?


For historical reasons, the Ruby web development community mostly uses Capybara and not Watir.  We might argue which is
better, but it would be pointless. Watir has always been intended for use by everyone, not just Ruby programmers, and we
carry on that design philosophy.