背景

RN 开发的项目 iOS 端尝试过直接使用 find_element_by_id, find_element_by_accessibility_id 都获取不到元素的情况下，又不能在代码中添加多余的标识代码，所以就只能使用 xpath 去定位元素了，后面使用过程中，虽然存在有一些空间获取不到 xpath 层级路径（如下图），但也还是比较少的情况，暂时就使用 tap 来解决了，后面再看看具体为什么获取不到了。

• appium inspector 查看，整个时间选择控件就是一个 text

• app-inspector 也一样

ConfigParser 配置 管理模块的 xpath

在使用过程中刚开始用的绝对层级的，发现 xpath 实在太长，直接放脚本代码中太占地方，导致脚本也不易维护，后面将 xpath 抽到 conf 配置文件，通过 key-value 方式获取，这个问题似乎得到解决了

看看这货有多长

//XCUIElementTypeApplication[1]/XCUIElementTypeWindow[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther[2]

通过文案内容定位精简 xpath

随着用例写的越来越多，而之前按模块来管理 xpath 文件方式的弊端慢慢就出来了，文件越来越多，而且很多元素其实似乎都是重用的，但是每个模块的都写了遍，这种冗余和臃肿肯定是接受不了，还得改造，于是就去了解xpath 语法，最后总结了几条基类的 xpath，发现基本够用。

• 查找文案匹配 (normalize-space 忽略空格)

base_element_equal_text = //*[normalize-space(@name)="%s"]

• 查找文案或另外某个文案匹配
  

base_element_last_equal_text = //*[normalize-space(@name)="%s"]| //*[normalize-space(@name)="%s"]

• 查找文案匹配的最后一个
  

base_element_last_equal_text = (//*[normalize-space(@name)="%s"])[last()]

• 查找 包含文案 匹配的最后一个

base_element_contains_text = (//*[contains(@name, "%s")])[last()]

• 查找某节点往上的第一个兄弟节点

preceding_sibling_element = //*[normalize-space(@name)="%s"]/preceding-sibling::*[1]

• 查找某节点往下的第一个兄弟节点

following_sibling_element = //*[normalize-space(@name)="%s"]/following-sibling::*[1]

• 查找某节点的父节点往上的第一个兄弟节点

parent_following_sibling_element = //*[normalize-space(@name)="%s"]/../following-sibling::*[1]

• 查找某节点的父节点往下的第一个兄弟节点

parent_preceding_sibling_element = //*[normalize-space(@name)="%s"]/../preceding-sibling::*[1]

封装对应的方法，调用时获取到 xpath 再拼接传入要查找的文案内容即可。

欢迎大家补充。