Pull to refresh

Comments 13

У них есть ряд проблем с запуском в CI на iOS, и при этом они толкают собственное облако - теперь за $500 в месяц.

Прилично, конечно. Да и кто будет платить столько сразу за новый, развивающийся инструмент?

Ну сами тесты мы таки сделали на них - это лучший e2e движок для React Native. Просто гоняем у себя.

Сколько боли я испытал в попытках автоматизировать React Native пару лет назад, используя Appium. Думаю, что действительно - на Maestro это бы работало куда лучше.

Да, ни detox ни appium не дают такого уровня стабильности и удобства.

Возможно вы просто не так пишите... (1000+ тестов под iOS + Android - проблемы что мешают пока только в не 100% стабильном сервере)

А ReactNative это общая боль в виду большой вложенности (особенно iOS).

В случае с iOS на данный момент есть ограничение, что фреймворк не работает с реальными устройствами - только с эмуляторами.

Уже провал.

Гибкость: возможность интеграции с CI/CD процессами

Это вообще не уместно. CI без разницы какой инструмент использовался для написания тестов.

Локаторы определяются через атрибуты ID, текст или позиции. Это упрощает их создание и обслуживание

Смешно. Если у элемента есть id или текст, то и в Appium будут простые локаторы.

по сравнению с Appium, где часто требуется сложная XPath-навигация

Если Appium’у требуется СЛОЖНЫЙ xpath, значит у элемента нет ни id, ни текста, ни других уникальных свойств. В этом случае и maestro не поможет.

Несмотря на проблемы в Appium (например, самая очевидная - управление ожиданиями элементов

Не проблема. Ни разу при нормальном подходе тесты на ожидании элемента не упадут.

Спасибо за комментарий!

Отвечаю по порядку:

Уже провал.

"Провал" в плане моей неточности? Нет, так написано на официальном сайте, что не работает с реальными устройствами. Конечно, это огромный минус

Это вообще не уместно. CI без разницы какой инструмент использовался для написания тестов.

Я упомянул потому что важно было понимать, что такая возможность имеется. Конечно, это имеется не только у этого фреймворка.

Смешно. Если у элемента есть id или текст, то и в Appium будут простые локаторы.

Согласен

Если Appium’у требуется СЛОЖНЫЙ xpath, значит у элемента нет ни id, ни текста, ни других уникальных свойств. В этом случае и maestro не поможет.

Соглашусь, да. При этом у Appium еще есть возможность "зрительного" (OpenCV) анализа элемента по картинке (поиск текста на самих картинках - findElementByImage). Не идеально, но хотя бы есть такая опция. У Maestro такого нет.

Не проблема. Ни разу при нормальном подходе тесты на ожидании элемента не упадут.

Тем не менее, ожидания в Appium очень хрупкая вещь, по крайней мере добавляет лишний код. Тот же Selenide довольно неплохо решает эту проблему.

А по факту - ценные уточнения и я только за живую дискуссию.

Провал" в плане моей неточности?

Нет, я имел ввиду что это серьезный недостаток инструмента

по крайней мере добавляет лишний код

Не могу согласиться. Вынести ожидание и получение элемента во враппер и пользоваться враппером везде вместо find_element. Вряд ли код, написанный для переиспользования и реализации какой либо функциональности (в данном случае «нормальное ожидание») можно назвать лишним. Разве что он «лишний» по сравнению с Selenide, где, судя по всему, эта функциональность не нуждается в реализации.

"Тем не менее, ожидания в Appium очень хрупкая вещь, по крайней мере добавляет лишний код." - вы вообще о чем? Вы пробовали Аппиум Java аннотации? Там во первых супер гибкая система ощидания. А во вторых xPath вообще отдыхает по степени сложности, какие можно задать в Java Appium annotations.

Я вам свой пример скину

https://discuss.appium.io/t/combining-iosclasschain-locators-issue/40162/3

А вот пример управления на лету временем поиска элементов

https://discuss.appium.io/t/withtimeout-pagefactory-annotation-and-implicit-or-explicit-waiting/41684/2

Спасибо за информацию! Действительно, интересно. Но здесь вопрос больше о том, что Appium позволяет "из коробки" без лишних модификаций и добавления более гибкой логики ожиданий.

Я лишь говорю о том, что появляются конкуренты, которые это все реализуют с меньшим количеством строк кода и нагляднее. То, что Appium при настройке классная вещь - никто и не спорит.

Если мы говорим и маленких проектах, где действительно надо только кликать - то возможно простота Маэстро выигрывает.

Но! Как только мы говорим о чем то более сложном, где в тестах на лету нужно создавать данные, пользователей используя много как API, так и DB обращений, то все становится намного сложнее. В таких проектах клики это лишь 30%, а сложная обвязка уже требует более высокого уровня инженеров. И таким людя пары строк настройки - вообще не проблема.

О том и речь. Maestro вряд ли подходит для сложных проектов сейчас. Впрочем, именно это я в статье и говорю.

Sign up to leave a comment.

Articles