Watir tips and tricks

I’ve been using Watir for a week or so now and have (naturally) run into a couple of problems. I’ve also come up with a handy way to reference fields on a page. I thought I’d share these tips so others won’t have to spend their precious time working through ’em as I had to do.

Problem: Watir doesn’t respect maxLength

The first problem I found is that Watir doesn’t respect the maxLength attribute on a text field. It will happily enter 20 characters into a text field with a maxLength of 10 without complaining. This can cause problems with assertions and such. I was able to override Watir’s set(..) method with code which will throw an exception if the string to be entered into the text field exceeds the maxLength.

Just add this code to your script if you want the same warning to show up:

class Watir::TextField
  alias_method :set_value, :set
    def set(value)
      if (value.size > maxLength)
        fail(“The length of the string < "#{value}"> exceeds ” +
          “the max length (#{maxLength}) of the “#{name}” text field.”)

Problem: Watir doesn’t yet handle JavaScript alerts

Another problem I ran into was Watir’s inability to handle JavaScript alerts and pop-ups. (It can handle pop-up browser windows fine, just not windows created with JavaScript’s alert(..) function.) There currently isn’t a very good workaround for this, but the Watir folks are working on a solution for the next release. In the meantime, they suggest using a tool call AutoIt in conjunction with Watir to automate interaction with the pop-ups. I haven’t tried this method yet.

Tip: Abstract out textual references to page elements

The site I’m using Watir to test changes quite frequently. I have no guarantee that a specific page element will be named the same thing for any length of time. Why, then, would I want to scatter references to the element throughout my Watir tests and be forced to change all of the references anytime the element itself is changed? My solution was to abstract out the common attributes of the element so that each element is only defined once. Then, whenever an element changes, I only have to change a single reference.

Ruby’s “method_missing” idiom made it very, very easy to do this. I simply defined a parent for all of my test cases and added the following method definition to it:

def method_missing(method)
  key = method.id2name
  super unless page_objects.has_key?(key)
  args = page_objects[key]
  return @ie.send(args[0], args[1], args[2])

Do you see what this does? Whenever a method which doesn’t exist in a subclass is called, method_missing is passed the name of the (non-existent) method. I take that name and use it as a key in a hash which I expect to be returned by a method called “page_objects” which is defined in a subclass. If the key exists, I grab the object from the hash and use it to call a method on Watir’s IE object (Ruby’s “send” method is the equivalent of an “exec” in other langages… it just allows strings to be interpreted as method calls and arguments).

I then define the “page_objects” method in each of my subclasses like so:

def page_objects
  “field1” => [:text_field, :id, “my_field”],
  “field2” => [:text_field, :id, “another_field”]

I can then simply reference “field1” and “field2” as if they were instance variables of my subclass. For example:

def test_example
  field1.setContents(“Hello world”)
  assert_equal(“Booyah”, field2.getContents)

The calls to “field1” and “field2” are handled by “method_missing” since those methods don’t exist, and the magic then proceeds from there. If the actual ID of either field changes, I simply make the change in my “page_objects” method and my existing tests should all continue working. This indirection follows the DRY principle (Don’t Repeat Yourself).

This trick would almost impossible to accomplish in Java without a large amount of bulky reflection code. Just another example of why dynamic typing is so nice.

Hope you find this idiom as useful as I have. Happy Watir-ing!

One thought on “Watir tips and tricks

  1. Pingback: just in ram » links for 2006-03-16

Comments are closed.