t.me/atinfo_chat Telegram группа по автоматизации тестирования

Подскажите, как организовать архитектуру мобильных автотестов

architecture
best-practices
mobile
android
appium
ios
Теги: #<Tag:0x00007f9e37f21ef8> #<Tag:0x00007f9e37f21db8> #<Tag:0x00007f9e37f21c78> #<Tag:0x00007f9e37f21b38> #<Tag:0x00007f9e37f219f8> #<Tag:0x00007f9e37f21890>

(Igor Vlasuyk) #1

Здравствуйте, друзья!
Начал заниматься мобильной автоматизацией, в связи с чем есть несколько вопросов к людям с опытом в этом деле. Итак:

  1. Должны ли быть разделены page классы для Android и для iOS? Насколько сильно может различаться поведение на этих платформах?
  2. Можно ли применять Selenide-appium для нативных приложений? Как мне кажется эта библиотека лучше подходит для гибридных и веб приложений на телефоне…
  3. Посоветуйте пожалуйста best-practices для мобильной автоматизации: статьи, видео.

Благодарю.

image|550x294 «og:image:width» и «og:image:height».


(Vladislav Sobol) #2

Разделять пейдж классы или нет как раз зависит от того на сколькотразные у вас приложения, если они разные то разделять, а если нет то зачем же, если твм и элементы одни и те же и делают они одно и тоже и флоу одинаковый.
Насчет того на сколько сильно может различаться поведение, тут тоже зависит от того как оба приложения сделаны и уже исходя из этого вы пишете пейджи и тесты.
Могу сказать на примере своего проекта, у нас приложения 99% одинаковы для ios/android, так что методы и тесты универсальны.


#3

+1, общий пейдж обджект пожалуй стоит делать только если приложения на 99% идентичны и тест кейсы соответственно тоже. Иначе придется сильно помучаться. Можно конечно выделять какие-то общие пейджобжекты для обоих платформ или переопределять некоторые методы для платформы, но по факту это сильно усложнит и написание и, особенно, поддержание тестов ап ту дейт. Вобщем если приложения не на 99% идентичны, я бы посоветовал делать разные пейдж обжекты и разные тесты. Может быть где-то будет копипаст, но в долгосрочной перспективе я думаю этот подход надежнее


#4

и еще один важный момент: Помните, что приложения могут обновляться не одновременно!
Допустим, у вас есть фича добавления продукта в корзину. Допустим, раньше при заказе продукта надо было 1) тапнуть на продукт 2) тапнуть на кнопку “добавить в корзину”. Вы соответственно делаете у себя метод какой-то orderItem(), который делает эти два действия. Но вдруг бизнес решает упростить подход - теперь при “тапе” на продукт он должен сразу добавиться в корзину. Андроид девелоперы успели ее переделать, а иос нет. Что делать с нашим методом в автотест проекте? Здесь есть гибкие решения, особенно если вы стронг в программировании. Но в целом я к тому, что более простым и надежным подходом будет все же разделять тесты и пейджобжекты


(Viktor) #5

в этом случае можно разные ветки сделать для Android и Ios и мержить мере поступления фич


(Михаил Братухин) #6

А потом следить за синхронизацией общих доработок в двух ветках? Тогда уж можно сразу два отдельных проекта делать. Это по сути мало чем отличается.


(Viktor) #7

Зачем следить? Они будут в конечном итоге одинаковые, если не втыкать и не забывать мержить. По сути это очень отличается, потому что в данном подходе вам нужно будет добавить только отличающиеся локаторы под OS и вовремя делать мерж в нужную ветку, вместо того чтобы поддерживать 2 проекта, которые практически идентичны.


(Михаил Братухин) #8

Есть ветка Android и ветка iOS. В них независимо вливаются свои доработки (так как релизный цикл у приложений отличается). При этом есть доработка какой-то общей функциональности или исправления общей ошибки. В случае двух веток нужно вливать эти коммиты в обе ветки, при этом коммиты, которые относятся только к одной платформе нужно вливать только в одну ветку. Как по мне, то тут можно очень быстро запутаться, начать что-то терять или вливать что-то что не нужно было вливать и т.д. В малых командах может и незаметно, но с ростом числа участников и веток начнутся проблемы, съедающие время всех участников.


(Viktor) #9

Конечно можно запутаться) для этого и есть процессы, gitflow. На каждую фичу создается отдельный бранч. Где гарантия что поддерживая 2 проекта отдельными репозиториями вы через время просто не забудете добавить фичи? Та проблема, про которую вы говорите, она так же само актуальна для того подхода который вы отстаиваете


(Михаил Братухин) #10

Нет, мне что тот, что второй подход кажутся равнозначными.
https://youtu.be/qfl0NqSN5uU


(Viktor) #11

Ну тогда предложите альтернативы)


(Vladislav Abramov) #12

да какая по факту разница? как удобно, так и делайте. никто не мешает из одного репозитория код копировать в другой, как и мержить ветки, черрипикать изменения и все такое

разработчики же как-то это проблему решают. В больших проектах специально берут релиз-инженеров, задача которых менеджить процессы поддержания актуальных стендов по веткам в репозиториях, так что проблема вполне решаема. Отличаются только костыли, которые придется городить в каждом конкретном случае


(Михаил Братухин) #13

Ищете «серебряную пулю»?
Универсальных рецептов нет, надо смотреть на проект и процессы. Но я бы в большинстве случаев смотрел в сторону неразрывной кодовой базы, а разделение логики делал через паттерны типа Стратегия или что-то типа того.


(frere123) #14

Ну ведь опенсорс рядом. Вообще проблема решаема еще и вопросом цены. И да релиз инженер все равно есть, чаще роль в команде, хотя и не звучит так гордо


#15

У меня на проекте android и ios наьивные приложения по функционалу идентичны на 90%. Page objects те же самые, естественно отличаются локаторы элементов. Действия над этими элементами тоже идентичны для двух платформ. Если необходимо специфичное поведение для одной из платформ (свайп какой-нибудь), то как правило template method паттерн это всё что нужно. Подозреваю что для мобильных web приложений разница в поведении для платформ будет минимальна. Тесты можно создать в одной ветке репозитория для обоих платформ