XCUITest driver supports the following location strategies in the native context:
Name | Description | Example |
---|---|---|
id, name, accessibility id | All these locator types are synonyms and internally get transformed into search by element's name attribute. |
my name |
className | Performs search by element's type attribute. The full list of supported XCUIElement type names could be found in the official XCTest documentation on XCUIElementType |
XCUIElementTypeButton |
-ios predicate string | This strategy is mapped to the native XCTest predicate locator. Check the NSPredicate cheat sheet for more details on how to build effective predicate expressions. All the supported element attributes could be used in these expressions. | (name == 'done' OR value == 'done') AND type IN {'XCUIElementTypeButton', 'XCUIElementTypeKey'} |
-ios class chain | This strategy is mapped to the native XCTest predicate locator, but with respect to the actual element tree hierarchy. Such locators are basically a supertype of -ios predicate string . Read Class Chain Queries Construction Rules for more details on how to build such locators. |
**/XCUIElementTypeCell[$name == 'done' OR value == 'done'$]/XCUIElementTypeButton[-1] |
xpath | For elements lookup using the Xpath strategy the driver uses the same XML tree that is generated by the page source API. This means such locators are the slowest (sometimes up to 10x slower) in comparison to the ones above, which all depend on native XCTest primitives, but are the most flexible. Use Xpath locators only if there is no other way to locate the given element. Only Xpath 1.0 is supported. | //XCUIElementTypeButton[@value=\"Regular\"]/parent::* |
Also, consider checking the How To Achieve The Best Lookup Performance article.