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.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have heard that, when using Selenium, the CSS Locator has better performance than the XPath Locator. Which Locator do you use in your tests? Have you seen a great performance improvement when using CSS Locators? Were there times when you had to use XPath instead of the corresponding CSS Locator?

share|improve this question
up vote 6 down vote accepted

Don't forget the not only performance is better with CSS locators, it's the compatibility too that matters.

We are testing on a multy browser environment in which we use: IE, SAFARI, FIREFOX, CHROME.

On IE the xpath almost never works OR it is SO slow that it can't be managed. So we use CSS where ever we can. Unfortunately IE does not support many CSS logics like, previous item, next item, counters and so on. But that can be arranged...

You have to tell your Developers to give distinctive IDs To every and each element you are using. It will greatly speed up your performance because you wont be needing to much XPATH magic to reach elements.

So conclusion:

CSS is better with IE that's for sure. On other browsers I didn't really spot any difference.

share|improve this answer
    
"IE does not support many CSS logics like, previous item, next item, counters and so on. But that can be arranged... " How do you arrange? – Tarun May 6 '11 at 8:44
    
Yeah, sorry.. arranged is continued on the below line. You have to tell your... etc,etc. But if needed in critical parts you still can use XPATH, just ceep it to a minimum. :) – Hannibal May 6 '11 at 10:37
1  
Saying that CSS is the best locator strategy in the first half of your answer, and then saying that to get it to work you need to get your devs to modify the source code in the secnd half surely shows that CSS is not the best in all cases. Whilst it can be slow on IE XPath requires not modification from devs to allow you to find your element, so you could in effect say XPath is better as a locator strategy unless you are doing primarily IE testing. Not a great answer IMHO. – Ardesco Jul 1 '11 at 14:03
    
I agree that XPATH is not so great on IE. But I would argue with not asking devs to add some distinctive IDs. How do you use xpath? Do you find elements (with xpath) by their position in DOM? I would do everything I could to get distinctive IDs instead. – yoosiba Jul 7 '11 at 14:12

Well, in fact I am using xpath. The best way is to put an static -of course unique- id to the elements you want to refer.

share|improve this answer
    
agreed but most of the times you get an application which does not have such testing hooks and you need to make you scripts work and find defects – Tarun May 6 '11 at 8:57
    
I know. We have an application which generates dynamic ids. I use different plugins for such as firebug and firefinder under Firefox. Another trick is to use a style class name which is unique for the element you are looking for. – Luixv May 6 '11 at 9:05
    
even style class is duplicated at times – Tarun May 6 '11 at 9:10
    
@Luixv I think you mean style id not style class name (for uniquesness). In practice I may use both (in combination) to identify a given element. Sometimes multiple classes class names can be used together to uniquely identify the element, e.g. table#primary/tr.header/td.cost – Michael Durrant Mar 20 at 10:57

An example of something you can only do in XPATH is go the parent of the current node. So while I recommend using CSS when you can, sometimes XPATH is the only way.

Edit : Actually, brain-fart on my side. The following site has two very useful charts that compare CSS and XPATH locators if those exist plus DOM locators for good measure, all with special notice to Selenium : http://www.simple-talk.com/dotnet/.net-framework/xpath,-css,-dom-and-selenium-the-rosetta-stone/

Very useful stuff.

share|improve this answer

In my experience xpath can be very flaky as it relies on the current structure of the UI for navigation. Change the page structure and whoosh, there go your tests.

For that reason, I prefer the stability of css selectors.

share|improve this answer
1  
I disagree, CSS locator also depends on current structure of UI for navigation. If UI changes CSS locator should also be broken. – Tarun May 6 '11 at 10:13
    
I agree with @CBA whole completely. We had originally used xpath for all of our selectors, and it quickly became apparent that using the class_name or id was the only way to write the tests in such a way that they would not need to be fixed for any small change to the html – Jason Ward May 6 '11 at 14:26
2  
xpath and css have almost same probability of breaking if the UI changes. Both depend on the current structure of UI. If UI elements are well identified i.e. can be uniquely identified with one or a combination of attributes, both xpath and css can be created in a very reliable way. If either of them is not created from the root, both can survive a few UI changes. – Suchit Parikh May 6 '11 at 17:04
    
@Jason I would suggest that you were using poorly constructed XPath's then, a well formed Selenium XPath will ne no more brittle than a CSS locator. – Ardesco May 18 '11 at 12:50
1  
I think there is confusion here between two independent interpretations of the question: 1) by which means to identify elements (ids, classes, or DOM paths) and 2) which language (and locator engine) to use, XPath or CSS – reinierpost Sep 19 '12 at 14:57

When CSS and ID are unique go for it, however, when the above two approach does not help in resolving finding unique nodes, then do not be shy to use 'relative xpath'

  • Use relative xpath w.r.t to a marker in the html section of interest
  • Use wild card features of xpath, always w.r.t marker
  • Use functionality that xpath engine provides e.g contains, text ..
  • Keep the relative xpath short. hint: A relative xpath may contain
    1. a marker + a wild card
    2. a marker + relative path to wild card+ wild card

Reference: http://www.simple-talk.com/dotnet/.net-framework/xpath,-css,-dom-and-selenium-the-rosetta-stone/

More hints: If relative xpath are used, and if relative xpath are readable, which it should, because we are finding location on html using xpath, w.r.t a marker, then, the xpath engines in all browsers are good enough to resolve them, in the year 2016.

of course, there could be some performance issue but there is no way, the current xpath engines would fail in any browser

Additional info: Relative xpath are as simple as or similar to, navigating folders relative to a current folder, on a command console or bash

Bad practice: Asking developers to provide additional ids or distinct css (just) for testing could appear simpler, but it will pollute the front-end code base with markers thats used only for QA. On a long term, its not the correct approach

Testability of app counts, however make sure, one has explored all the options

Circumstances when CSS and ID may not helpful: When a javascript package, example extjs used, then the html generated in those cases, selecting unique elements based on CSS may result in multiple nodes from 10's to 100's. Also, IDs change based on extjs updates and based on browser (Strange case, but true)

@michael durrant: provides a nice and a very simple example of case: when css is better or equivalent to xpath and when it comes to question of 'readability'. Of course, 'absolute xpath' should not be considered as it gets long. I have been insisting only on 'relative' xpath throughout above

share|improve this answer

I have used both css and xpath locators.

Generally the first tool of choice is css. The syntax is more compact, there are additional functions both basic for all browsers and advanced for some. There is also less of a tendancy to use a browser function (say from right-click) or tool that provides an xpath for copying that includes the entire page structure which will change over time. To be specific, using css tends to lead to selectors such as span[name='cars'] rather than //body//div/spn/span/table/tr/tr/tr/td/td/td/td/span[@name='cars']

My second choice is xpath for special circumstances. Once I needed to find an element and then 'back up' several same level elements and xpath seemed the only way to navigate around the DOM that way, i.e. relative addressing. However the selectors tend to have more characters making the intent harder to read.

Other than syntax, both approaches present similar challenges as to the best way to identify elements in ways that guarantee uniqueness but don't make tests brittle and easy to break by being hard-coded to the current page layout.

Similarly element ID's can be great for a simple and unique (f programmed correctly) way to identify elements. This requires coordination with developers and can then be leveraged by both css and xpath selectors.

The supposed performance advantage of xpath seems largely refuted by http://elementalselenium.com/tips/32-xpath-vs-css showing a very minor improvement, and if ignoring Opera, basically none.
The article also makes a point that css tends to reflect how developers name objects themselves which makes them easier to maintain when both use the same approach.

css also supports wildcards for attributes such as

  • "begins with class" class^=
  • "ends with id" - id$=
  • "name contains text - name*=
share|improve this answer

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.