Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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?

share|improve this question
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 Jul 1 '11 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 Jul 7 '11 at 14:04
    
Are you sure the name doesn't have spaces in it? Does By.xpath("//input[contains(@name,'soemName')]") work? –  Ardesco Jul 12 '11 at 8:20
    
The post on stackoverflow.com/questions/4346479/… tells more about doifferent locators performance –  dzieciou Nov 2 '12 at 21:42
add comment

3 Answers

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... ;)

share|improve this answer
add comment

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.

share|improve this answer
    
-1 because answer is not backed up by any facts or link, so it sounds like a subjective perception of performance. –  dzieciou Aug 31 '13 at 15:15
add comment

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

share|improve this answer
    
-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 Aug 31 '13 at 15:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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