Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
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?
Don't forget that not only performance is better with CSS locators, it's the compatibility too that matters.
We are testing on a multi 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 each and every element you are using. It will greatly speed up your performance because you won't be needing too 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.
Well, in fact I am using xpath. The best way is to put a static (of course unique) id to the elements you want to refer.
table#primary/tr.header/td.cost
Mar 20, 2016 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.
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.
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
class^=id$= name*=
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'
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
