Wednesday 9 February 2011

Lessons from a WATIR to WATIR-Webdriver port - #4 When assert_true is no longer assert_true

I wanted to record problems found (and perhaps solved?) while attempting to port a test automation framework from WATIR to WATIR - Webdriver, and a simple blog entry seemed to be the easiest way.


This problem may be just faced by myself and the caused by the versions of TestUnit, Watir & Webdriver I am using, but just in case other people are having the same issue, here it is for google to find!


For the same test, Assert_True was passing when using WATIR, but failing when using Watir-Webdriver.


After tearing my hair out for a while I realised that when using WATIR, assert_true comes from more-assertions.rb in a gem called s4t-utils, where as when I ran the test as WATIR-Webdriver, the assert_true from the testunit gem is used.


The assert_true in TestUnit gem is far stricter in that the value must be boolean true to pass, where as the other assert_true takes advantage of the fact that in Ruby, anything which isn't nil is true.


Personally, I like the version which insists the value is boolean true, so have decided to change the tests to follow this, although obviously I could have overridden it with the less strict version.


As I said, this problem will not affect everyone, perhaps it's only me, but I wanted it recorded!



Lessons from a WATIR to WATIR-Webdriver port - #3 Ruby meets strong typing

I wanted to record problems found (and perhaps solved?) while attempting to port a test automation framework from WATIR to WATIR - Webdriver, and a simple blog entry seemed to be the easiest way.


WATIR is far less strict than Webdriver about the classes you use to access objects in the html, presumably this because Webdriver is written in Java(???) and that is derives its tag_name from teh class itself.


If I have a visible object which looks like a button but in the html is actually a link, then WATIR is far more forgiving.


For example;


 <a href="http://www.google.com" id="goog">Goto Google</a>


Using id, WATIR allows me several ways to access the object, such as;


@browser.button(:id, "goog")
@browser.link(:id, "goog")


However, with Webdriver, I have to use the class define in the html.  Therefore only the following is valid.


@browser.link(:id, "goog")  NB. I believe Link is an alias of "a", therefore "a" is valid too


If you were to use "button", you would get the following error;


Watir::Exception::UnknownObjectException: unable to locate element, using {:tag_name=>"button", :id=>"goog"}


This is obviously not a big problem, but as I said, exposes mistakes which WATIR allowed and requires changes if those mistakes were made



Tuesday 8 February 2011

Lessons from a WATIR to WATIR-Webdriver port - #2 Add_checker can still be my friend

I wanted to record problems found (and perhaps solved?) while attempting to port a test automation framework from WATIR to WATIR - Webdriver, and a simple blog entry seemed to be the easiest way.

A colleague advised me that tests ported from WATIR ran extremely slow on IE, and that this was caused by our use of AddCheckers (http://rubydoc.info/gems/watir-webdriver/0.1.7/Watir/Browser#add_checker-instance_method)

As a result, it was assumed that;

add_checker + webdriver = BAD


However, this is not true.  The reason the add_checkers appeared to be slow on IE, was because we used the Text method on the Browser class to scan for certain text on the page.  This is extremely slow in IE for webdriver.


Therefore, add_checkers can be used in webdriver as long as you do not use browser.text

Monday 7 February 2011

Lessons from a WATIR to WATIR-Webdriver port - #1 When it comes to Firefox, size matters

I wanted to record problems found (and perhaps solved?) while attempting to port a test automation framework from WATIR to WATIR - Webdriver, and a simple blog entry seemed to be the easiest way.


Slow Firefox Startup


I was finding that it was taking upwards of 30 seconds to launch Firefox at the start of a test.  This compared badly with WATIR, where the same test was a few seconds.

The problem;

As part of Selenium::WebDriver::Firefox::Launcher, the FF profile is copied to a temporary folder.  This uses FileUtils.cp_r and appears to be slow.

The solution:

Make sure the firefox profile used on your test run machine is as small as possible.  I removed Firebug, EditCookies and a few other add-ons, and this reduced the start up time to a few seconds and comparable to WATIR