Я пытаюсь найти заголовок приложения для iOS не зависящим от страниц способом. Этот заголовок виден на всех страницах и всегда находится в следующей цепочке классов:
header_class_chain = '**/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther/XCUIElementTypeOther'
Эта цепочка классов выполняет глобальный поиск всех элементов типа XCUIElementTypeOther глубиной 14 уровней. Я не могу выполнить поиск по accessibility_id, потому что эти теги не существуют, и я не ожидаю, что они будут добавлены в ближайшее время.
В Appium Inspector, когда я выполняю поиск в вышеуказанной цепочке классов с помощью self.driver.find_element((MobileBy.IOS_CLASS_CHAIN, header_class_chain)), я всегда нахожу нужный элемент заголовка, независимо от того, нахожусь ли я на странице, к которой есть прямой доступ из меню в приложении, или на какой-либо дочерней странице. Таким образом, я предположил, что мог бы использовать эту цепочку классов, чтобы найти заголовок независимо от содержимого страницы.
Однако, когда я запускаю тестовый скрипт в режиме автоматизации, поиск в этой цепочке классов находит заголовок ТОЛЬКО на страницах, которые напрямую доступны через меню. Я ожидаю, что эта цепочка классов будет функционировать при автоматизации так же, как она работает вручную, то есть находит заголовок на любой отображаемой странице.
Два интересных наблюдения, которые могут или не могут помочь. Во-первых, идентификатор элемента заголовка, сообщаемый Appium, не изменяется, пока приложение находится в заданном рабочем процессе. То есть, если бы я проходил рабочий процесс покупки, идентификатор заголовка в Appium оставался постоянным до тех пор, пока я не закончу рабочий процесс или не перейду на другую страницу через меню. Я наблюдал это поведение как вручную через Appium Inspector, так и в журналах от автоматических тестовых прогонов.
Во-вторых, при поиске заголовка на дочерней странице я видел следующие строки в журналах Appium:
[WD Proxy] Got response with status 200: "{\n \"value\" : false,\n \"sessionId\" : \"4C72B56A-C6C6-4D9A-850E-3C95EE014E29\",\n \"status\" : 0\n}"
[WD Proxy] Replacing sessionId 4C72B56A-C6C6-4D9A-850E-3C95EE014E29 with 3a91c7cb-d660-48b4-8b2d-144dbaecfaae
Когда я начал свой тест, журналы сообщали [info] [35m[BaseDriver][39m Session created with session id: 3a91c7cb-d660-48b4-8b2d-144dbaecfaae.
Вскоре после этого в моем тестовом прогоне был представлен еще один идентификатор сеанса: [debug] [35m[WD Proxy][39m Got response with status 200: {"value":{"sessionId":"4C72B56A-C6C6-4D9A-850E-3C95EE014E29","capabilities":{"device":"iphone","browserName":"APPNAME","sdkVersion":"12.1","CFBundleIdentifier":"com.COMPANY.APPNAME"}},"sessionId":"4C72B56A-C6C6-4D9A-850E-3C95EE014E29","status":0} (имя приложения отредактировано, поскольку приложение еще не доступно для общественности).
Я не достаточно знаком с Appium, чтобы исключить возможность того, что эти 2 sessionIds являются причиной моего поиска. Если бы я догадался, я бы сказал, что базовый драйвер, на котором запущено приложение, содержит sessionId, начинающийся с 3a91, и WebDriverAgent назначается 4C72 sessionID, и что WebDriverAgent каким-то образом взаимодействует с базовым драйвером. Опять же, это всего лишь обоснованное предположение, и оно, вероятно, имеет отношение к моей реальной проблеме: Appium не нашел элемент заголовка там, где я явно этого ожидаю.
Почему этот вызов завершается вручную, но не выполняется автоматически?
Как я могу изменить свой код, чтобы найти заголовок, независимо от того, на какой странице я нахожусь?