I understand your point on removing options in Katalon… But I am a bit disapointed as Xpath is a powerful way to handle HTML documents and, to speed-up test creation and execution.
Hence, I would rather pledge for an update to Xpath2.0 and a little clean up of the attributes detection interface. There is really interesting functions in the v.2.0.
WebUI.verifyElementPresent(findTestObject( 'Page_Discussion 7609/td_Latin_alphabet - text matches'),
where the Test Object has a XPath defined as
When I run the test case, Katalon Studio calls org.openqa.selenium.WebDriver.findElement(By.ByXpath). The string //td(matches(text(),'IVAN')) is transferred from Katalon Studio to browser (for example, Chrome). Chrome browser interprets the string //td(matches(text(),'IVAN')) as XPath, and evaluate it against the DOM of a Web page.
The thing is, it is browsers (Chrome, Firefox, etc) who evaluates the string //td(matches(text(),'IVAN')) as an XPath expression. Katalon Studio does not know if the string is an expression conformant to XPath1.0 or XPath2.0. All Katalon Studio does is saving the string and transferring it to browsers. It depends on Browser’s capability if it supports XPath 2.0 or not. According to https://stackoverflow.com/questions/25455351/does-chrome-use-xpath-2-0 , Chrome uses libxml which supports XPath 1.0 but not XPath 2.0.
If you want to use XPath 2.0 expression in Katalon Studio, then you need to convince the Browser vendors (Google, Mozzila, Microsoft, Apple) to hear your wishes. I believe that Katalon Team has very little they can do for changing Chrome and Firefox.
And I guess, Browser vendors will not be interested in XPath2.0 support; they are serious about CSS and JavaScrit, but not about XPath features any longer.
In KSE 7.2.1, the “matches regex”, “not matches regex”, and “ends with” conditions provided for selecting objects by attributes do not work. If this is dependent on browser support, and none of the browsers Katalon uses support XPath 2.0, why are the options still present in Katalon?
Yes I agree that it is misleading that these do not work. Either they should be removed or fixed. I am running into this issue with mobile… with this is a selector: //*[ends-with(@resource-id, ‘child_start_button’)] @ThanhTo@duyluong
I need this to work too, I need to match the current month / year and many other cases on a text of a testObject, and regex seems to be the closest to what I need that would not involve a lot of workarounds… Ideally I would like to match the current month or year on a text of testObject(s) but that involves coding and reorganizing a lot of repository objects and consequent adjustments. We need the simplest solution for our needs.