Selenium is a great tool. We have a bunch of Selenium tests that run with every one of our builds. Unfortunately, they contain a bunch of XPath in them to verify elements, and the XPath engine in IE6, to put things lightly, is a piece of garbage. It takes a huge amount of time to verify an element in a page.
As an example, here is the amount of time that our Selenium test run used to take on Firefox:
Finished in 506.108548 seconds
And here's how long it took on IE:
Finished in 4567.47592 seconds
That's 1 hour and 16 minutes to the same set of tests that it takes less than 9 minutes to run in Firefox. Clearly this is unacceptable, and, from watching the tests run, it's clear that the IE XPath engine is to blame.
We decided to attack this problem by using Hpricot to verify the elements in a page instead of the built in XPath engine. This allows us to use Selenium for navigation between pages in our site and Hpricot to do the verification.
It's simple enough to grab the HTML from the page at any point during a Selenium test by using
(as long as you're using Ruby Selenium Driver) and then you can do all of the verification that you want on it, in far less time. Plus, the number of changes that you have to make to your Specs/Tests are minimal. As an example,
readouts_table = table('id=readouts') readouts_table.cell(0,0).should contain_text("Molecule")
in our old code became
doc = Hpricot(@browser.get_html_source) readouts_table = doc/"//table[@id='readouts']" readouts_table/"thead/tr".should == "Molecule"
in our updated code.
As always though, the proof is in the pudding. I've updated 2 out of 19 of our specs, and our time on Firefox has dropped to:
Finished in 488.753052 seconds
But more importantly, out IE run time is now:
Finished in 3171.07507 seconds
That's a 24 minute difference already and we can already fit in a couple of extra CI builds a day because of that.
We're planning on adopting this strategy for all of our Selenium tests moving forward. Selenium will be used only for navigation, and Hpricot will be used for verifying the page content. I strongly suggest that you consider it instead of using the built in verification.