Support xpath support for cy.get() and .find()

[fringd]

Current behavior:

.get('//div') doesn't work .find('p/span') also doesn't work

Desired behavior:

It gets the element using document.evaluate just like get and find currently uses document.querySelector.

or to avoid collisions we add getXpath and findXpath or something.

Motivation

xpath is fairly standard in integration tests, and is much more powerful than css selectors are, and I'm working on a shared library of xpath selectors for use with selenium, puppeteer, and ideally, cypress.

I'm happy to help with writing this code if people agree it's a useful feature that would be likely to get merged.

[Hellsfoul]

What about //parent::div ? When I remember correctly, I also had issues with chaining too many cypress commands after cy.get In additon it is bad, when I have to use the locator multiple times in the code. Then, I have to chain the same cypress commands multiple times.

[scorpyto]

contains

First of all "contains" is so useless when you have multiple similar elements and second -> chain commands are kinda broken, especially with .get command.

[luciarodriguez]

+1 from me, even more now that cypress/xpath is no longer supported.

[Sindhuboston]

+1 for xpath please

[satkunas]

+1 for xpath support

[betole]

1+ for xpath support.

[umeetiusbaar]

+1 for xpath support

[jgonzalezalbisu]

A very large part of the Cypress users will appreciate that this is prioritized. Thanks!

[dil-ddasmohapatra]

+1 for xpath support. It's realy helps a lot while integrating with UI elements.

[mateusjsilva]

+1 for xpath support

[kiranHanumantharaya]

+1 for xpath support.

[wieben]

+1 Coming from Selenium to Cypress testing, what seems hard in Cypress is targeting the below button with comment in this piece of DOM

<div>
    <div data-w-component="my-panel">
        <div>
            <div><span>Panel title to ignore</span></div>
        </div>
        <div>
            <div>
                <button>Click here</button>
            </div>
        </div>
    </div>
    <div data-w-component="my-panel">
        <div>
            <div><span>Panel title</span></div>
        </div>
        <div>
            <div>
                <button>do not Click here</button>
            </div>
        </div>
        <div>
            <div>
                <button>Click here</button> <!-- this button should be targeted -->
            </div>
        </div>
    </div>
</div>

The xpath that would do it

//*[@data-w-component="my-panel" and .//*[text()="This panel"]]//*[text()="Click here"]

It allows the button to be targeted leaving the DOM to be able to change in all possible ways, except changes to data-w-component attribute, or changes to the title of the panel, or changes to the text of the button. If Cypress can do that with as little constraint on changes to the DOM, then xpath would not be missed that badly.

[wieben]

If Cypress can do that

It can do something close. For the example in above post the below code clicks the desired button. This Cypress test will break if another panel is nested around the title, whereas the Selenium/XPath test would keep passing.

cy.get('[data-w-component="my-panel"]')
            .contains('*', /^This panel$/)
            .parents('[data-w-component="my-panel"]')
            .contains('*', /^Click here$/)
            .click()

[dqiubread]

how has this not been prioritized since the xpath package has been deprecated?

[allancostaquality]

+1 for Cypress to be able to support the use of xpath natively. It seems that the Cy team’s thinking is only geared towards development, where only the simplest and fastest is considered. Xpath is undoubtedly a selector infinitely more powerful than the CSS Selector.

Not to mention teams that would like to migrate from other frameworks and already use xpath and won’t break their heads to change all selectors to CSS.

[alexsch01]

As Salesforce Lightning element testing requires xpath (https://github.com/cypress-io/cypress/issues/29294) and the xpath package has been deprecated, I give +1 for this issue (I would usually not comment just to give +1, but this issue is different)

[dqiubread]

I've been having same issues as @alexsch01 here with testing Salesforce Lightning Elements and sometimes the shadow elements are not recognized so we have to use xpath. @bahmutov, @jennifer-shehane as Salesforce is custom LWC made by salesforce which will not have data-testids and use a ton of shadow containers is there any support for this?

[bahmutov]

Shadow support is different from xpath. On the personal note regarding xpath selectors: don’t use them. Sent from my iPhoneOn Apr 9, 2024, at 10:14, dqiubread @.***> wrote: I've been having same issues as @alexsch01 here with testing Salesforce Lightning Elements and sometimes the shadow elements are not recognized so we have to use Cypress. @bahmutov, @jennifer-shehane as Salesforce is custom LWC made by salesforce which will not have data-testids and use a ton of shadow containers is there any support for this?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[dqiubread]

@bahmutov, the problem for us is that in our salesforce application its really hard to tell what is and isnt a shadow dom element since salesforce does not explicitly tell you if the element type is inside a shadow element. Instead of for me requesting for a feature on shadow dom elements where idk where the issue is coming from, it would be easier to get xpath support as developer tools already supports it so to me it feels more of a universal solution.

[bahmutov]

Can’t you set cypress option to traverse the shadow borders by default?Sent from my iPhoneOn Apr 9, 2024, at 10:41, dqiubread @.***> wrote: @bahmutov, the problem for us is that in our salesforce application its really hard to tell what is and isnt a shadow dom element since salesforce does not explicitly tell you if the element type is inside a shadow element. Instead of for me requesting for a feature on shadow dom elements where idk where the issue is coming from, it would be easier to get xpath support as developer tools already supports it so to me it feels more of a universal solution.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[dqiubread]

@bahmutov, I turned the includeShadowDom to true to try to resolve the issue, but for some reason for some of the elements like these elements where they have an aura class or aura id in salesforce, it sometimes fails to get the element by the classname or id. I was told that the elements are alls built from salesforce so not sure how much custom stuff the development team has done. The reason my team uses xpath is we are able to get these elements that have these aura classes which cy.get and cy.contains for some reason is not able to handle for Saleforce

[DMaguireKane]

Seems we can add the now removed @cypress/xpath code to our commands.js to get back the cy.xpath(...) functionality, just copy&paste the following into commands.js : @cypress/xpath index.js

• doesn't cover .get and .find but better than no xpath support

[dqiubread]

Seems we can add the now removed @cypress/xpath code to our commands.js to get back the cy.xpath(...) functionality, just copy&paste the following into commands.js : @cypress/xpath index.js

• doesn't cover .get and .find but better than no xpath support

I'm not totally understanding. Wasn't .get and .find never supported? Also Cypress xpath has been removed from the master branch, do you mean we can just make a custom command using what existed of the xpath functionality from before?

[DMaguireKane]

do you mean we can just make a custom command using what existed of the xpath functionality from before?

Yes, copy&paste the full content of the @cypress/xpath index.js linked above (which is linked to the commit before they removed the content) into your command.js and it appears to restore cy.xpath(...) capability (at least in my minimal usage of it so far). It's a crappy workaround for lack of xpath support and potentially will break in the future. I then mentioned that it doesn't cover .get and .find simply as this git issue is specifically about adding xpath support to .get and .find.

[jgonzalezalbisu]

do you mean we can just make a custom command using what existed of the xpath functionality from before?

Yes, copy&paste the full content of the @cypress/xpath index.js linked above (which is linked to the commit before they removed the content) into your command.js and it appears to restore cy.xpath(...) capability (at least in my minimal usage of it so far). It's a crappy workaround for lack of xpath support and potentially will break in the future. I then mentioned that it doesn't cover .get and .find simply as this git issue is specifically about adding xpath support to .get and .find.

@DMaguireKane despite it has been deprecated, is still available for download in the npmjs, why do you suggest we do this to use cy.xpath()command?

[DMaguireKane]

@jgonzalezalbisu Ah, I somehow assumed that it was removed because it no longer worked. Apologies for the wasted notifications. Installing @cypress/xpath and adding require('@cypress/xpath') to command.js still works fine (and add "@cypress/xpath" to tsconfig.json types for intellisense).

[jgonzalezalbisu]

@jgonzalezalbisu Ah, I somehow assumed that it was removed because it no longer worked. Apologies for the wasted notifications. Installing @cypress/xpath and adding require('@cypress/xpath') to command.js still works fine (and add "@cypress/xpath" to tsconfig.json types for intellisense).

@DMaguireKane nothing to apologize for!