Just Another Framework - for developing watir test cases

Recently I attended Railscamp 08 in Sydney Australia for a weekend of code, beer and bzflag. For my ‘project’ I decided on brushing up my my Ruby skills and constructing a simple framework from which I could structure watir test cases.

Specifically I wanted to achieve the following:

To that end I was reasonably successful. The only limitation was that I only had my macbookpro with me and probably would have been shunned even if I attempted to load a windows XP virtual machine at a rails camp full of mac and linux geeks. So I chose FireWatir as my test platform running on my Mac, but am reasonably comfortable you can easily port this framework for use with Watir.

Now on with the framework contents …

In the attached zip file file you will find the following directory/file structure, with the following explanation provided for each.

./run.rb : this is the controller, with the general intent to be able to set global options here, such as run Firefox in the background, or specify an iteration count for test cases.
./setup.rb : setup is called by run.rb, and is the orchestration layer for running the test cases. This file also dynamically loads required libraries as well as the object Modules from my object repository for each page in the application under test.
./results.html : this is an example output when the test suite is run using rspec with the –format html parameter argument.
./data/test_data.yaml : an example of a small data set using a yaml format
./objects : an example of the objects in my ‘object repository’ dynamically created
customerloginsubstruct.rb
homesubstruct.rb
storesubstruct.rb
./tests : a couple of examples of test cases using rspec and testunit.
rspecdemo_test.rb
testunitdemo_test.rb
./util/discoverobjects.rb : a utility script which ‘learns’ objects on a page, which using reflection you can then later re-use in a DSL’ish kind of fashion. Should cut down on the amount of code you have to write when constructing test cases and implements a standard for naming objects on a page.

How to use the framework …
The path to using this framework is to first utilize the DiscoverObjects class. The purpose of this script is to scan a page for common watir objects such as links, text_fields and buttons and create a list of ‘objects’ in a new Module. Modules in Ruby allow you to incorporate methods in other classes. So for example, if you open up the AUT to a certain page, for example the logon page, then you can run the script to learn those objects on that page:

ruby discoverobjects.rb

The script output will be a suggested structure for your Module. For example:

module Customerloginsubstruct
# Objects learned from: http://localhost:3000/customers/login
# Sun Jun 22 11:22:30 +1000 2008
  def text_field_name_login
    return @b.text_field(:name, "login")
  end
end

You can see some example objects created from a demo application (Substruct) in the objects subdirectory.

Why am I taking this approach?
In the first instance I was sick of using FireBug or the IE Developer toolbar to individually pick elements on a page and learn their attributes when writing test cases. This process does it for me automatically.
Secondly, it now gives me a form of version control between developer code release. So if elements change on a page, for example developer removes or adds attributes, I should be able to easily diff my object repositories.
It also gives me a more generalized naming standard, or more predictable. For example a text link can be called by writing link_text_shopping_cart.click instead of @b.link(:text ‘Shopping Cart’). I’m hoping this format is more user friendly for the non-developer type testers who want to write test cases quickly. Obviously people’s opinion might differ on this

Running the RSpec tests …
I found the following options useful to run from the command line using rspec:

spec run.rb --format specdoc -c
spec run.rb --format html > ./results.html
spec run.rb --format profile -c


Have a play around and see what you think. I found the html format to be most useful. As it is updated progressively, you could output this to your common web server so that people can easily check progress of long running automation test suites. This is all just food for thought. Let me know what you think and if there are any improvements you can offer.