When you come across methods in watir that return child objects for the first time (eg: the ‘lis‘ in @browser.ul(:id,’main’).lis ) you’d think they’d return only the direct child objects. Frustratingly, they don’t. They’ll also return nested objects of the same type. Here’s some example html:

<ul id='main'>
  <li></li>
  <li> </li>
  <li>
  <ul>
    <li></li>
  </ul>
  </li>
</ul>
  

If you call @browser.ul(:id, 'main').lis.length (to get the number of child li objects), you’d get the answer: 4. Intuitively, you’d expect to get the answer 3. Well, I would, and everyone else I’ve mentioned this to agrees [grumble grumble]. Now the example above is trivial – in the real world, nesting ul‘s in li‘s is common and can get quite complex. It gets even more complex when what you really want is to be able to type the following:

@browser.ul(:id,'main').lis[4].links[7]

…but instead you end up writing convoluted, complex, fragile and unmaintainable code to do what you’d think the above code should do – get the 7th link that is a direct child of the 4th li element that is a direct child of the ul.

But, there is a solution. Perversely, the solution is part of the watir/firewatir code. If you’re prepared to use xpath to identify your objects (my personal preference is to always use xpath), there’s a great method called elements_by_xpath which will do exactly what you want. Again, using the example above, you can get 3 as the answer (number of direct child li’s of the ul) with the following code:

@browser.elements_by_xpath("//ul[@id='main']/li").length

Even better, in doing the following:

my_lis = []
my_lis = @browser.elements_by_xpath("//ul[@id='main']/li")

…the my_lis variable will contain an array of elements; each element being of the right type – Li‘s in this instance. This works with links, table rows, table cells… everything! You can go back to writing clean, maintainable tests!

Note, this works in watir and firewatir. I haven’t checked safariwatir…

Testing a web app in an unstable environment is a pain. Many tests will fail for environmental reasons and filtering out those results can take a while. To make this sort of thing less painful, Watir and its derivatives (eg: firewatir) provide the ability to run any number of methods each time a page is loaded. They call these methods “checkers”… because… they check stuff. Here’s how to use them:

1) Write your checker
Checkers are Ruby Procs – essentially, nameless methods stored in variables. Here’s an example:

check_for_bad_things = Proc.new do
  puts "Server Error!" if @browser.text.include?("server error")
end

2) Add the checker to your instance of the browser

@browser = Watir::Browser.new
@browser.add_checker(check_for_bad_things)

3) Run your test. Every time a page is loaded, the check_for_bad_things proc is executed; and instead of seeing obscure failures when the test environment dies, you’ll see a message saying “Server Error!” making it easy to spot tests that failed for environmental/non-regression reasons.

You can make the checkers more useful by making them throw exceptions instead of just printing a line to the console. This way, they’ll cause tests to end with error instead of failed, making it even easier to sort out real failed tests from fails due to environment instability.