Join us at the Test Automation Bazaar

On March 23rd and 24th (Friday and Saturday), the Watir Conference and Test Automation Bazaar will be held in Austin, Texas. I am hosting this event with Alister Scott, Hugh McGowan and as much of the Watir Team as we can get to Austin. This conference is for the Watir Community and any one who wants to learn more about how people are successfully automating testing. As Watir users are turning to using Selenium’s Webdriver technology, the focus is less on the traditional Watir/IE core and more on using what works, whether that be Watir, Selenium, Capybara or whatever. It’s not even necessarily about web-testing. We are, however, mostly looking for solutions in Ruby and Ruby will be the official language of the conference. We are looking for people to join us and help us make this the best place in the world to learn about effective automated testing. Because we are taking this broad focus, we are calling this a Test Automation Bazaar.

We will follow this schedule on both days:

 9:00 - 12:00    Presentations with moderated discussions
12:00 -  1:00    Lunch
 1:00 -  2:00    Lightning Talks
 2:00 -  4:30    Open Space
 4:30 -  5:00    Group Circle

Therefore we are looking for people who would like to give short, focussed presentations of 10–20 minutes each for the mornings. These will be followed by 5–20 minutes of moderated discussion. The actual time will be determined by the moderators based on the interest level of the audience. We are also looking for 5 minute lightning talks. The morning program and the lightning talks will be single-track, so they will be tightly facilitated. The open space in the afternoon will be multi-tracked and will provide an opportunity for breakout groups, coding demonstrations, and impromptu collaborations. If you have ideas of things you would like to present please contact Alister Scott and me with your ideas. We want to have lots of short presentations from lots of different people.

For some, this may be an unusual format, but it is based on years of experience organizing small conferences. The morning program is based on the LAWST format that we have used in the AWTA workshops and comes from the Context-Driven Testing community. Lightning talks come from the open-source community. And Open Space has been popular in Agile circles. People don’t learn from long lectures, so we are trying to make this as interactive as possible.

If this sounds like fun, please join our mailing list (where we are organizing the conference) and buy a ticket. I am asking everyone who plans to attend to buy a ticket, whether you are host or a speaker or a volunteer. I’ve already bought mine. We don’t have event staff, so we will need lots of help. This is a conference by and for the Watir community.

The conference’s primary financial purpose is to fund the travel expenses to allow the Watir Team to all meet face-to-face. Our team is distributed around the world, so this isn’t easy or cheap. This goal is consistent with membership in the Software Freedom Conservancy a non-profit umbrella group that we are in the process of applying to join. In order to help with this, we are asking everyone attending to buy a ticket, so our overseas contributors can make their plans.

Right now we are offering a limited number of “Early Bird Volunteer” tickets. This includes organizers, speakers, volunteers. We have already started accepting proposals, but will not be selecting “speakers” until very late in the process. We want to work with presenters to help them with their talks and will probably be arranging the program up until the last minute. This is how we have always done it with the Lawst format. Recently I realized that this really amounts to using the Fieldstone writing method to conference planning. So if you have made a proposal and are discussing it with us, please go ahead and consider yourself eligible for the volunteer ticket. We need help with facilitation, particularly from people with experience with the Lawst, Lightning or Open Space formats. We are also looking for people to blog and tweet and video record the event so that the people who can’t make it can benefit. We are also are trying to organize charity workshops for March 22. Maybe you can help with that. Please join our mailing list, where we have been discussing volunteer needs. We also consider any one who has been contributing to the Watir project, answering questions, blogging about what they’ve been doing, to be volunteers. Being a volunteer is as much a state of mind, a willingness to pitch in and help others, rather than just watch the world go by. Buy your ticket today.

Watir Day 2011 Tickets now available for $50

Tickets to Watir Day 2011 on Sunday 3rd April 2011 in San Francisco are now on sale for $50 each.

Don’t forget about the sponsorship deal where your employer or company can be a sponsor for just $175 and receive four free tickets. This sponsorship can be purchased through the main ticket page too.

All proceeds from the event go to cover costs and to support the Watir project. And to cover the cost of your special Watir Day t-shirt (include your t-shirt size when you register).

More information about Watir Day can be found here.

Alister Scott: A simple Cucumber + Watir page object pattern framework

This post by Alister Scott originally appeared on Please leave all comments on the original article.


I was very impressed with Jeff Morgan, known as Cheezy, who recently wrote a series of blog posts about how to use Cucumber and Watir, and shared his code on Github.

I love it when people share their ideas this like, so I thought I would share what I have found useful when setting up a very simple Cucumber with Watir (Celerity & Watir-WebDriver) page object pattern framework, and how this compares to what Jeff has proposed.

Show me the code!

Before we begin, I’ll show you my code. It’s all on Github, right now, as we speak, and you can easily fork and clone this repository to play around with it. It uses a simple google search example.

Project Folder Structure

Google Search Feature

Feature: Google Search
  As a casual internet user
  I want to find some information about watir, and do a quick conversion
  So that I can be knowledgeable being

Scenario: Search for Watir
  Given I am on the Google Home Page
  When I search for "Watir"
  Then I should see at least 100,000 results

Scenario: Do a unit conversion
  Given I am on the Google Home Page
  When I convert 10 cm to inches
  Then I should see the conversion result
            "10 centimeters = 3.93700787 inches"

Scenario: Do a search using data specified externally
  Given I am on the Google Home Page
  When I search for a ridiculously small number of results
  Then I should see at most 5 results

Page Object Pattern

For our example, we have two page objects. The page classes delegate any methods that don’t exist on the page to the Browser object that is passed in from Cucumber. This ensures you can call browser specific methods (.title, .url etc.) at the page object level without duplicating methods.

class GoogleHomePage

  attr_accessor :search_field, :google_search_button

  URLS = { :production => "" }

  def initialize(browser)
    @browser = browser
    @search_field         = @browser.text_field(:name => "q")
    @google_search_button = @browser.button(:name => "btnG")

  def method_missing(sym, *args, &block)
    @browser.send sym, *args, &block

  def visit
    @browser.goto URLS[:production]

  def page_title

  def search_for term
    self.search_field.set term
    google_results_page =
    google_results_page.results.wait_until_present if WEBDRIVER


Cucumber Initialization

I have everything to do with initialization in support/env.rb. This initializes a browser once, and then uses the same browser instance for each Cucumber scenario. This is different from Jeff’s hooks.rb file that launches a new browser for every scenario. I have found by reusing the browser, you get much quicker test execution time.

The INDEX_OFFSET is a constant that allows me to use ‘index’ when referring to browser elements across both celerity with its 1-based index and watir-webdriver with its 0-based index.

TEST_DATA_DIR = "./features/test_data"

if ENV["HEADLESS"] then
  require "celerity"
  browser =
  WEBDRIVER = false
  require 'watir-webdriver'
  require 'watir-webdriver/extensions/wait'
  browser = :firefox
  WEBDRIVER = true

Before do
  @browser = browser

at_exit do

Calling the page objects from the steps

As you can see, most of my steps are in a declarative style, so these normally align pretty well to a method on the page object.
I use a given step to create a page object (in our case @google_home_page), and then call methods on this object for when and then steps. I have created a dynamic invocation of the page creation, so it will work for all pages specified in the cucumber step itself. I use the search_for_term method to transition between page objects, as this method returns the new page. As a rule of thumb, I try to keep my step definition code to 1 or 2 lines, and at a fairly high level, which makes it much more readable.

Given /^I am on the (.+)$/ do |page_name|
  @google_home_page = Object.const_get(page_name.gsub(" ","")).new(@browser)

When /^I search for a? ?"([^"]*)"$/ do |term|
  @google_results_page = @google_home_page.search_for term

When /^I search for a?n? ?([^"].+[^"])$/ do |term|
  term = Common.get_search_term_data term
  @google_results_page = @google_home_page.search_for term

Then /^I should see at least ([\d,]+) results$/ do |exp_num_results|
  @google_results_page.number_search_results.should >= exp_num_results.gsub(",","").to_i

Then /^I should see at most ([\d,]+) results$/ do |exp_num_results|
  @google_results_page.number_search_results.should <= exp_num_results.gsub(",","").to_i

When /^I convert (.+)$/ do |conversion_statement|
  @google_results_page = @google_home_page.search_for "convert #{conversion_statement}"

Then /^I should see the conversion result "([^"]*)"$/ do |exp_conversion_result|
  @google_results_page.conversion_result.text.should == exp_conversion_result

Expressing test data external to the features/pages

Unlike Jeff’s recommendation of using default data on page objects, I prefer to store test data externally to the page objects in YAML files. That way I can describe the test data which is directly used in my Cucumber step. For example:

Scenario: Do a search using data specified externally
  Given I am on the Google Home Page
  When I search for a ridiculously small number of results
  Then I should see at most 5 results

The phrase ridiculously small number of results matches directly to a section of my YAML test data file. This keeps the scenario highly readable, with the detailed data specified in the YAML file.

search terms:
  ridiculously small number of results:
    search term: 'macrocryoglobulinemia marvel'

A common method simply retrieves the appropriate test data, and provides it to the step to use. Note here that, as this step doesn’t contain quotation marks, this implies a description of data, rather than a literal string of data that would contain quotation marks around the string.

When /^I search for a?n? ?([^"].+[^"])$/ do |term|
  term = Common.get_search_term_data term
  @google_results_page = @google_home_page.search_for term

Putting it all together
I have set up two profiles in the cucumber.yml file, one is the default that uses Firefox under Watir-Webdriver, and one runs Celerity (headless) and is named ci. It’s then a case of calling "cucumber" or "cucumber -p ci" to run each of these profiles.

I have set up a ./go script that bootstraps the entire process on unix based systems (Mac OSX and Linux).

The final result

Running cucumber provides results as green as a cucumber.

How does this compare to Cheezy’s framework I mentioned?

  • I am using a similar page object pattern to define web application pages, but I haven’t created a helper class to mix into each like he has: I simply use instance variables on a page class to define the GUI elements, instead of creating a series of methods for each object.
  • My page objects also delegate methods to the main Browser object as required, so you can directly call things like .title, .url etc.
  • Instead of using Jeff’s default data pattern, I instead prefer to store this data described in external YAML files instead for maximum flexibility.
  • Jeff talks about using mixins to mix in common objects. I haven’t done this, but it’s easily doable with my framework, and should be done as it scales out.


Jeff has done an excellent job with his series of posts and code (thank you), and I am hoping here to build on that, and show how it’s easy to set up a simple Cucumber & Watir page object pattern framework.

Alister Scott on ‘How to set up Cucumber and Watir on OSX’

Guest post by Alister Scott

These are the steps I had to use to get Cucumber and Watir running on OSX. It’s a shame about step 1, it’s a real pain but I don’t know any way around it.

  1. Install Xcode from OSX installation DVD – this takes about 15 minutes
  2. Open a command prompt and use enter the following commands.
  3. sudo gem update --system
  4. sudo gem install rspec --no-rdoc --no-ri
  5. sudo gem install gherkin --no-rdoc --no-ri
  6. sudo gem install cucumber --no-rdoc --no-ri
  7. sudo gem install firewatir --no-rdoc --no-ri

You should be good to go.

See original post:

Watir 1.6.6 RC2 is out

Hello (fire)watirists!

We are happy to announce that a (very) long-waited (Fire)Watir
1.6.6.rc2 is out! Please grab it now.

Changes from rc1 include:

  • A main README.rdoc file (Zeljko)
  • Unit test fixes for Firewatir (Zeljko)
  • Ability to run unit tests from gems (Jarmo)
  • Additional unit test and bug fixes (Jarmo)

You can check out the full changelog at

Make sure your local gem system is up to date.

gem update --system
run gem -v at the command line, you should be running 1.3.7

gem install (fire)watir --pre

Note: If you’re installing on Mac or Linux you’ll want to use
firewatir for the gem install.
…and give it a go. Try to use it with your existing test suites and
so on to see if there are any issues.

If there are any problems then:

  1. Fix it and send a pull request on Github, our main github repo: This is the preferred way of accepting patches, we’re happy to work with you on how to do this, github also has extensive docs on how to fork and submit a pull request.
  2. Add it to our JIRA tracker:
  3. If you need help with that let us know.

With your help, we will be getting out a final version of 1.6.6 shortly and working on continuously rolling out releases on a quick timeline. We already have actions lined up for 1.6.7 which should be released fairly quickly as we make our way through the current tickets and changes and roll them into releases.

If you do have time and can help, please let us know, we can take any help from documentation to running tests on various OSes. We’re a
friendly project and would be happy to mentor you if you and/or your company is willing to put in the time.

Charley & Jarmo

Watir 1.6.5 Released

Version 1.6.5

For the latest version of release notes, please see

New Features (Both IE and Firefox)

  • Browser.attach is now available.
  • Browser.options and Browser.set_options are now available.
  • Add support for definition lists, this adds these methods:
    • dd, dt, dl, dds, dts, dls. (Jarib)
  • Hidden#visible? should always return false. (Jarib)
  • New method execute_script.
  • Add ElementCollections#size as alias of length. (Jarib)
  • Some camelCase => snake_case renames (with aliasing). (Jarib)
    • Image#fileCreatedDate => file_created_date
    • Image#fileSize => file_size
    • Image#hasLoaded? => loaded?
    • SelectList#getAllContents => options
    • SelectList#getSelectedItems => selected_options
    • SelectList#clearSelection => clear
    • SelectList#includes? => include?
    • TextField#dragContentsTo => drag_contents_to
    • Radio/Checkbox#isSet? => set?
  • Patch for winclicker fix. (Derek Berner)
  • Add support for using a Regexp as the third argument (value) when locating checkboxes/radio buttons. (Jarib)
  • Add support for element. (Jarib)
  • Add support and tests for element. (Jarib)
  • SelectList#select now supports Numeric arguments. (Jarib)
  • Additional inspect implementations for both IE and FF. (Jarib)
  • Added ElementCollections#{first,last}. (Jarib)
  • Fixes for running on Ruby 1.9. (Jarib)

Firefox Improvements

  • SelectList#set is now defined for Firefox. Like with IE, it is an alias for SelectList#select. [271]
  • Element collections are now enumerable. This allows methods such as @select@ and @map@ to be used with methods such as @divs@ and @links@.
  • FireWatir.attach is now available, analogous to IE.attach.
  • Some Javascript errors that were being ignored, now raise Ruby exceptions.
  • Added event handler which resets the context of document
  • Fix bug that occurred when new page was automatically loaded. (Angrez, 3ef8b6) when page gets loaded automatically (Angrez)
  • Changed code to use document_var, body_var, window_var, browser_var instead of “document”, “body”, “window”, “browser” variables. (Angrez)
  • Changed code to replace every quote (“) in xpath query with (\”) so that it doesn’t give error while executing the xpath query (Angrez)
  • Fire onchange event for FireWatir file fields. Closes WTR-286. (Jarib)
  • Fixes for running and closing Firefox on Mac OS X
  • Added functionality to allow Watir::Browser.attach with no arguments to open a new firefox window rather than taking over the existing focused window (Rob Aldred)
  • Also modified some setup functions to correctly handle closed browsers, browserless windows and others (Rob Aldred)
  • Add test and implementation for Firefox#status (Jarib)
  • Two problems fixed with .click (jubishop)
  • When chaining together element calls the @container becomes an HTMLElement, but there’s no container_var defined for HTMLElement
  • When an <a tag has no href then element_type was returning nil.
  • Fix bug in Firefox#document. change creating error class by eval in jssh socket to creating class with ruby.

IE Improvements

Structure Improvements

Unit Tests