Selenium IE performance issues; Tests optimization

As started in my previous post Selenium supports XPath expressions, which is actually one of the most commonly used DOM element location strategies. Unfortunately people complain about slower tests in IE (the problem is explained in details and discussed here) because of the XPath as well as of some failing tests in IE, created for example with Selenium IDE in Firefox. These are due to the fact that Selenium includes external library in order to support XPath in IE too and Firefox supports it internally. So in other words, Selenium XPath support definitely differs in IE and Firefox.

Almost two years ago, when I started working with Selenium here at Telerik, I was happy to see my first tests passing and simulating successfully some user actions. I had written hundreds of tests before I found the significant difference in the execution time in IE compared to Firefox. Now I always do my best not simply to write a test covering specific scenario, but to make it as optimized as possible. Is this necessary? 

Look at the screen shots below. This is just a suite of RadGrid Selenium tests.

[FF 2.0.0.4]

[IE 7.0.6730.11]

So those tests pass for about 8 minutes in Firefox, but require ~15 minutes in IE. Well, I still can optimize them a bit… 

Now imagine customers that are waiting for a stable build or even release. Imagine all the RadControls tests available being executed tens of times daily. We definitely need to have tests that run as fast as possible!

What can we do to optimize the tests? 

Here is a list of some solutions I’m after:

         1)       Use the best command for the particular case! I’ll take a command, verifying the text of the given element: 

Simple test scenario implementations:
-          Check the existence of an element, having specified ID and text
-          Check whether the element with given ID has the expected text 

Both do the same, but the second sounds better, doesn’t it? Here’s the source: 

assertElementPresent | //span[@id=’mySpanId’ and text()=’mySpanText’] |

assertText | mySpanId | mySpanText

Furthermore, as soon as you know the API and use the best command, creating such tests is much easier.

Consider using store/verify/assertValue as well. This one is an assertText alternative, but for the input elements.

2)       Avoid using XPath when IDs are available!

Ask your devs to add IDs to the elements you need to use! ;-) This is serious and I have a really fresh example. 

During the past week, our RadInput controls got new rendering! This will help us avoid some layout issues, etc. I asked our devs to add IDs to the input sub-elements like the Go and Spin buttons:

http://www.telerik.com/demos/aspnet/Input/Examples/RadTextBox/Settings/DefaultCS.aspx
http://www.telerik.com/demos/aspnet/Input/Examples/RadNumericTextBox/Formatting/DefaultCS.aspx 

So I no longer need to use complex expressions like:

click | //span[@id=’ RadTextBox1_wrapper’]/span/a/img[@alt=’Go’] |

to simulate pressing those controls. Instead, the action looks much better now: 

click | RadTextBox1_GoButton |

and is definitely faster!

3)       Use precise expression, to avoid continuous XPath engine iterations

As I mentioned in my previous post, the XPather Firefox Add-on will give you the full XPath to the required element really easily. However, I dislike using the full XPath as the tests become so ugly and maintaining them is a nightmare! The technique I like is something in the middle. 

A. Start from the top of the control, whose element you’d like to locate (most RadControls for example include a div element as wrapper) and go through the tree of its elements to the required one. For instance, I like starting from our Web Grid’s table element (see the screen shots/examples from my previous post). This makes reading the test easier as well.

B. Use the parent element, which will make the expression a bit more specific.

Say there are a couple of input elements around the page, having different and unique parents. Creating an expression, which includes the parent like //parentType[parentAttribute]/requiredChild will make the test faster for sure. Point A is actually a private case of this one.

Generally speaking, make your expression as precise as possible, but without breaking test’s readability! 

Conclusion: We always talk about product quality, but I believe we should also pay attention to the quality of our automated tests. Making the tests run faster and still keeping them easily readable will be worthwhile.