12

I am planning to run my existing Selenium 1.x tests in IE 8.0.

After checking few blogs and reading this, I tried to run my tests using jQuery locators with the method mentioned here. My tests uses a lot of index based selectors, like in xpath=div[class='myclass][index].

In jQuery I tried .myclass:eq(index) to retrieve the elements. But I found jQuery to be much slower than XPath in IE and Firefox for these operations. Is there a faster way in jQuery to select nth element?

Improve this question
4
  • 1
    I don't have any metrics but I would expect CSS to be the fastest in IE8. jQuery has a JavaScript dependancy, as does XPath in IE8 (As IE8 doesn't support XPath nativly so has to run through a JavaScript libraray). IE's JavaScript performance is lacking.
    – Ardesco
    Commented Jul 1, 2011 at 9:55
  • And IE xpath is not reliable. For example I found that in my test when I do By.name("soemName") it finds WebElement, and when I do By.xpath("//input[@name='soemName']") it doesn't. On FF both work perfectly.
    – yoosiba
    Commented Jul 7, 2011 at 14:04
  • Are you sure the name doesn't have spaces in it? Does By.xpath("//input[contains(@name,'soemName')]") work?
    – Ardesco
    Commented Jul 12, 2011 at 8:20
  • The post on stackoverflow.com/questions/4346479/… tells more about doifferent locators performance
    – dzieciou
    Commented Nov 2, 2012 at 21:42

3 Answers 3

Reset to default
3

No jQuery will not be faster.

IE has a very slow JavaScript engine compared to other modern browsers. Using jQuery selectors means you are using JavaScript to query the DOM, so you are instantly limited by IE's JavaScript engine. XPath support in IE is also via a JavaScript library (Google's wicked good xpath library), so XPath's will also be slow.

The fastest locator strategy in IE is CSS because of its native support, of course different versions of IE have differing support for CSS and as a result different CSS locators are supported in different versions of IE.

All of the above makes IE an absolute joy to automate... ;)

Improve this answer
-1

We use the following three different locators in the project

XPath using Ajaxslt library XPath using Javascript library jQuery Selector The tests are created from Tellurium Issues page and include three sets

A series of test flow including issue search and issue data access Similar to the first one but without group locating in UI modules Access data from the issue table (limit the size to 20 rows and 10 columns)

http://code.google.com/p/aost/wiki/TelluriumjQuerySelector

How to enable custom jQuery selectors in robotframework-seleniumlibrary

Selenium Library 2.3 introduces an ability to register and use a custom location strategy to locate elements on the website. The new strategy must be loaded by selenium-server.jar. This guide will explain how to enable location strategy based on jQuery.

http://code.google.com/p/robotframework-seleniumlibrary/wiki/jQueryElementSelectors

Improve this answer
1
  • 1
    -1: because The question was rather about performance of different locators types, and your answer does not relate to that at all. How does your post answer the question?
    – dzieciou
    Commented Aug 31, 2013 at 15:16
-1

I did some analysis long time back on CSS, jQuery and XPath and I feel jQuery is not giving better results than CSS and XPath. and CSS is little faster than XPath.

Improve this answer
1
  • -1 because answer is not backed up by any facts or link, so it sounds like a subjective perception of performance.
    – dzieciou
    Commented Aug 31, 2013 at 15:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.