search

appium / dotnet-client

Extension to the official Selenium dotnet webdriver
Apache License 2.0
381 stars 186 forks source link

[Feat]: RelativeBy functionality from Selenium 4 #760

Open aaronportier opened 6 months ago

aaronportier commented 6 months ago

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. I have radio buttons and check boxes next to text that contains automation IDs it would be nice to tell my app left of instead of creating automation IDs for checkboxes.

Describe the solution you'd like Selenium 4 brought RelativeBy functionality. I would love to use that in appium.

Describe alternatives you've considered Automation IDs everywhere on everything.

Additional context I see lots of deprecation for newer Selenium functionality but not a whole lot of new and added functionality that Selenium should bring.

Dor-bl commented 6 months ago

Related article: https://saucelabs.com/resources/blog/selenium-4-relative-locators

mykola-mokhnach commented 6 months ago

These locators rely on the native implementation. In case of selenium/browser automation it is easy to do something like that since under the hood they have css location. As a result, relative locators could easily be transformed into native ones. There is completely different story on mobile platforms though. Neither XCTest nor UIAutomator frameworks implement the concept of relative locators. For us, as backend developers, this means we'd need to map such locators into xpath ones, as it is the only locator type, which supports the idea of search axes. It's not only failry complicated task, but also a slow one, since xpath is the slowest location strategy (it's completely "artificial" and is not supported natively, especially in case of XCTest, where various XPath locators may take 10x to 100x more time in comparison to native ones)

Dor-bl commented 6 months ago

Let alone we can't easily inherit from this class (RelativeBy) since it's not abstract. @titusfortner @nvborisenko is there a plan for making RelativeBy abstract? Or is there a good reason behind it

nvborisenko commented 6 months ago

static members, what are not considered as inheritable? In any case we are open for any non-breaking changes (as quick win). Please propose your ideas, I don't see barriers for changes (breaking changes?..).

nvborisenko commented 6 months ago

Ah, forgot to answer on your question. RelativeBy will not be abstract in discoverable future, it is concrete type. I don't see problems to make some parts as virtual.