Why One Should Prefer Using CSS Over Xpath in Ie

Why one should prefer using CSS over XPath in IE?

According to Ashley Wilson's report from sauce labs:

Pros:

1. They’re faster
2. They’re more readable
3. CSS is jQuery’s locating strategy
4. No one else uses XPATH anyways!

It's a bit outdated, however here are the numbers:

Personally, I would argue about (2)-nd statement, I must agree with the rest.

Cons:

1. No "bottom up" navigation. XPath has elem\..\another_elem
2. Is Sizzle injected? Or Browser's CSS locator parser is used? Depends on the browser, and there are inconsistencies.

Why should I ever use CSS selectors as opposed to XPath for automated testing?

JeffC's answer here does plenty to sum up the pros and cons of each locator strategy. But I'll address your points specifically.

First off, there is no need for anyone to convince you that selectors are better, because from a purely functional standpoint, they simply aren't (and I'm saying this as someone with a gold css-selectors tag badge and almost 1000 answers to questions with that tag, so you know I'm not biased). If you're more comfortable with XPath, use it — in terms of features and what you can do, XPath is vastly superior, there really is no contest there. And, as you correctly state, performance is no longer an issue (if it ever was).

Selectors are there for quick and simple use cases and for users coming from HTML and CSS codebases, such as web developers, who want to get started with automated tests without having to learn another DSL. If you're responsible for the CSS of your own site you can also easily copy selectors from your stylesheet into your tests depending on what exactly you're testing.

If on the other hand you're coming from an XML/XSLT/XPath background, wonderful, you get to keep using the XPath you know and love¹!

Yes, Xpath is way more durable than CSS because it can invoke specific content contains functionality.

Having a content contains feature doesn't make XPath more "durable" — it makes it more versatile. If you rely solely on an element's content and that content can potentially change or move around, your XPath becomes no less brittle than a selector that relies solely on an element's attributes or its position in the DOM tree.

You can do any of a number of things to make your XPath or selector more or less brittle, but that's an indicator of how versatile the DSL is, not how brittle it inherently is.

---

¹ _{Depending on what version of XPath you're used to.}

What is the difference between cssSelector & Xpath and which is better with respect to performance for cross browser testing?

CSS selectors perform far better than Xpath and it is well documented in Selenium community. Here are some reasons,

• Xpath engines are different in each browser, hence make them inconsistent
• IE does not have a native xpath engine, therefore selenium injects its own xpath engine for compatibility of its API. Hence we lose the advantage of using native browser features that WebDriver inherently promotes.
• Xpath tend to become complex and hence make hard to read in my opinion

However there are some situations where, you need to use xpath, for example, searching for a parent element or searching element by its text (I wouldn't recommend the later).

You can read blog from Simon here . He also recommends CSS over Xpath.

If you are testing content then do not use selectors that are dependent on the content of the elements. That will be a maintenance nightmare for every locale. Try talking with developers and use techniques that they used to externalize the text in the application, like dictionaries or resource bundles etc. Here is my blog that explains it in detail.

edit 1

Thanks to @parishodak, here is the link which provides the numbers proving that CSS performance is better

Is xPath the preferred way to target an element during Selenium testing or a fallback?

The "preferred" way of locating the elements is using their ID attributes, as per Choosing a Location Strategy chapter:

Using an element ID or name locator is the most efficient in terms of test performance, and also makes your test code more readable, assuming the ID or name within the page source is well-named. XPath statements take longer to process since the browser must run its XPath processor. XPath has been known to be especially slow in Internet Explorer version 7. Locating via a link’s text is often convenient and performs well. This technique is specific to links though. Also, if the link’s text is likely to change frequently, locating by the element would be the better choice.

On the other hand, XPath is the most powerful option as:

• it has full access to the page DOM
• you're able to traverse DOM Axes and query elements children/parents/siblings, ancestors, etc.
• you're able to apply functions and operators like contains(), starts-with(), and, or, not, etc. so you're able to locate any element at any page using XPath which is not the case for other selector strategies.

In Selenium Webdriver which is better in terms of performance Linktext or css?

I'm just writing some points from this reference which is already provided by GK27 in comments, The purpose of writing here is to be clear if page has not found some time, user can view from here.

So the better way of locating the element, Priority wise should be in the list [id, name, linkText, partialLinkText, tagName, className, cssSelector, xpath] here first value id in the list contains first priority and so on.

Locating an Element By ID:

The most efficient way and preferred way to locate an element on a web page is By ID. ID will be the unique on web page which can be easily identified.
IDs are the safest and fastest locator option and should always be the first choice

Locating an Element By Name:

When there is no Id to use, the next worth seeing if the desired element has a name attribute. But make sure there the name cannot be unique all the times. If there are multiple names, Selenium will always perform action on the first matching element

Locating an Element By LinkText:

Finding an element with link text is very simple. But make sure, there is only one unique link on the web page. If there are multiple links with the same link text (such as repeated header and footer menu links), in such cases Selenium will perform action on the first matching element with link.

Locating an Element By Partial LinkText:

In the same way as LinkText, PartialLinkText also works in the same pattern, only difference is that it's match link with partial text means uses contains.

Locating an Element By TagName:

TagName can be used with Group elements like , Select and check-boxes / dropdowns.

Locating an Element By Class Name:

There may be multiple elements with the same class name, if we just use findElementByClassName, make sure it is only one. If not the you need to extend using the classname and its sub elements.

CSS Selector:

CSS mainly used to provide style rules for the web pages and we can use for identifying one or more elements in the web page using css.
If you start using css selectors to identify elements, you will love the speed when compared with XPath.
We can you use Css Selectors to make sure scripts run with the same speed in IE browser. CSS selector is always the best possible way to locate complex elements in the page.
If you have a need to find an element using a complex selector, I usually recommend using CSS Selectors, if possible. It's not quite as flexible as XPath, but will cover many of the same cases, without exhibiting the extreme performance penalty on IE that XPath can.

XPath Selector:

Finding elements by XPath is useful for finding elements using very complex selectors, and is the most flexible selection strategy, but it has the potential to be very slow, particularly in IE. In IE 6, 7, or 8, finding by XPath can be an order of magnitude slower than doing the same in Firefox. IE provides no native XPath-over-HTML solution, so the project must use a JavaScript XPath implementation, and the JavaScript engine in legacy versions of IE really is that much slower.

There are two types of xpath

1. Native Xpath, it is like directing the xpath to go in direct way. like
   Example:
   html/head/body/table/tr/td

Here the advantage of specifying native path is, finding an element is very easy as we are mention the direct path. But if there is any change in the path (if some thing has been added/removed) then that xpath will break.

2. Relative Xpath.
   In relative xpath we will provide the relative path, it is like we will tell the xpath to find an element by telling the path in between.
   Advantage here is, if at all there is any change in the html that works fine, until unless that particular path has changed. Finding address will be quite difficult as it need to check each and every node to find that path.

XPath different in IE and Firefox. Why?

*[Id=] denotes that it can be any element while the second one clearly mentions selenium to look ONLY for INPUT fields which have id as Search_Fields_profile_docno_input. The second xpath is better due to following reasons

1. It takes more time to find the element using * as IDs of all elements should be matched.
2. If your HTML code is not "well written" there could be other elements which have the same id and this could cause your test to fail.

---

Related Topics