An excellent conversation popped up on Slack about XPaths vs CSS selectors recently.
One member said
It’s more powerful than CSS. There are things that Xpath can do that CSS cannot. You can do things like find text containing etc… I have used it before for a particularly complicated cases where I needed to find all the specific elements after a certain element number (It was a dynamic site and had a draggable row, that was coded in html to be similar to the other rows but slightly different. Can’t remember the exact use case but it was not remotely possible in CSS)
I think… Xpath gets a bad rep… because people don’t read too much into it, and see horrible absolute xpaths copied directly out of chrome that look like this /body/div/div/div/span[4]...
I agree that is horrible . But that is not good xpath.
it gets a bad rep because most examples are copied directly out of the browser.
I am genuinely suprised, that CSS seems to be the dominant selector over xpath, I feel had we better educational resources on xpath, it would be the dominant selector as you can do more with it
A better answer would probably list what you can do in xpath vs CSS
Another member said
i see the point of the bigger feature set. but the need to use these features is a smell to me, a bandaid on the underlying problem that your UI isn’t well structured, the html not very descriptive.
also the smaller feature set and less special characters makes selectors better to learn, read and maintain in my opinion.
Both posters agreed that they’d seen some very poorly written CSS selectors over the years too though.
It could well be! Is was also developed as a part of XQuery, a very useful functional language for manipulating XML. I have used it to program using the open source database eXist. Together with XSLT I found it very easy to test and get right, since one can test the XSLT transforms with simple visual tools whilst developing and the simply set up test suites with the XML input and output. The XQuery code is also rather simple to test, since there are no global writable variables. What goes into an XQuery function must come out. The testing tools in eXist are rather primitive. I have not used the commercial XML database MarkLogic. That might be better. But as a sort of replacement for JQuery and CSS selectors I don’t know. Whenever somebody starts writing HTML, they write <div> before even thinking.
I have also been wondering why XPath is not so popular. I personally like to use relative XPath to locate web elements. I know some browsers have extensions that help you get the relative and absolute XPaths. This makes it easy sometimes. Chrome has ChroPath. and older versions of Firefox had FirePath.
People talk about the slowness of XPath like it’s something that they can measure and that can actually make a difference.
But the same people will have no problem with using a CSS Selector.
Maybe because CSS Selectors are easier to use with JavaScript and everything seems to be about JavaScript these days.
I can’t say I’m a fan of XPath and don’t enjoy reading through it at all, but I have seen instances, using WebDriver, where xpath is more consistent. For example, on a current system under test navigating through some of the menus can be done By.xpath or By.cssSelector (excuse the pun). In this instance, the latter is usually quite a bit more readable! Quite late on in my development, when running the code a lot more intensively, I found WebDriver would occasionally randomly decide a perfectly visible (and previously working/interactable) thing was not interactable at all.
I have no idea if this is a bug in the underlying framework, used by the software engineers, or a bug with WebDriver, but found switching to xpath* worked like a charm. And this is testing a system that has been largely very pleasant to automate, owned by a very cooperative software engineer** - I feel for those who must work on some of the inevitable nightmares out there.
* After trying explicit waits, hovers and so on. Sometimes WebDriver just doesn’t want to work with an element when I think it should.
** It’s an older team, with quite a few CAMRA members, so pretty chilled. There’s nothing that can’t be solved over a beer.
Unfortunately, a number of web frameworks use dynamic IDs and names, leaving the poor sod automating the thing with few choices. A well chosen CSS locator or a well chosen XPath locator isn’t a code smell.
Adea, here you should try SelectorsHub in place of chropath. SelectorsHub is the advance version of chropath, created by same developer. It’s available for all browsers.
Aria selectors ARIA - Accessibility | MDN , So this is really about coming full circle and forcing app developers to build well written apps that work for disabled users, but also work for testers.
Now as someone who has never written a web app, I’m no expert, but from my pairing on issues in Vue code, I can tell, that when apps use a framework (there are so many out there,) the framework will often be doing the standards compliant stuff for you and all the developer has to do is pass in a parameter with the id. Here is where the trouble starts. I recall this being a real fun issue 20 years ago with GUI development. Someone in marketing wants a fancy progress bar, someone in engineering thinks clickable links, or tooltips in the GUI that’s where nice things start, and in HTML… So the big thing I often now encounter is the Framework will add a CSS ID quite happily to an element, but the element will be obscured, and I’ll end up having to use javascript to either change it’s state, or use a selenium action chain to make it interactive. so I end up in my testing code having inconsistent approaches. And that’s the big smell for me. I’m still learning the XPATH selector query language. I found a good guide for it once, but now I cannot find the guide anymore. I hate how the web (or my brain) works like that. But for me, I’m happy with a well written XPATH query.
. But that is not good xpath.
