Разделять пейдж классы или нет как раз зависит от того на сколькотразные у вас приложения, если они разные то разделять, а если нет то зачем же, если твм и элементы одни и те же и делают они одно и тоже и флоу одинаковый.
Насчет того на сколько сильно может различаться поведение, тут тоже зависит от того как оба приложения сделаны и уже исходя из этого вы пишете пейджи и тесты.
Могу сказать на примере своего проекта, у нас приложения 99% одинаковы для ios/android, так что методы и тесты универсальны.
+1, общий пейдж обджект пожалуй стоит делать только если приложения на 99% идентичны и тест кейсы соответственно тоже. Иначе придется сильно помучаться. Можно конечно выделять какие-то общие пейджобжекты для обоих платформ или переопределять некоторые методы для платформы, но по факту это сильно усложнит и написание и, особенно, поддержание тестов ап ту дейт. Вобщем если приложения не на 99% идентичны, я бы посоветовал делать разные пейдж обжекты и разные тесты. Может быть где-то будет копипаст, но в долгосрочной перспективе я думаю этот подход надежнее
и еще один важный момент: Помните, что приложения могут обновляться не одновременно!
Допустим, у вас есть фича добавления продукта в корзину. Допустим, раньше при заказе продукта надо было 1) тапнуть на продукт 2) тапнуть на кнопку “добавить в корзину”. Вы соответственно делаете у себя метод какой-то orderItem(), который делает эти два действия. Но вдруг бизнес решает упростить подход - теперь при “тапе” на продукт он должен сразу добавиться в корзину. Андроид девелоперы успели ее переделать, а иос нет. Что делать с нашим методом в автотест проекте? Здесь есть гибкие решения, особенно если вы стронг в программировании. Но в целом я к тому, что более простым и надежным подходом будет все же разделять тесты и пейджобжекты
Зачем следить? Они будут в конечном итоге одинаковые, если не втыкать и не забывать мержить. По сути это очень отличается, потому что в данном подходе вам нужно будет добавить только отличающиеся локаторы под OS и вовремя делать мерж в нужную ветку, вместо того чтобы поддерживать 2 проекта, которые практически идентичны.
Есть ветка Android и ветка iOS. В них независимо вливаются свои доработки (так как релизный цикл у приложений отличается). При этом есть доработка какой-то общей функциональности или исправления общей ошибки. В случае двух веток нужно вливать эти коммиты в обе ветки, при этом коммиты, которые относятся только к одной платформе нужно вливать только в одну ветку. Как по мне, то тут можно очень быстро запутаться, начать что-то терять или вливать что-то что не нужно было вливать и т.д. В малых командах может и незаметно, но с ростом числа участников и веток начнутся проблемы, съедающие время всех участников.
Конечно можно запутаться) для этого и есть процессы, gitflow. На каждую фичу создается отдельный бранч. Где гарантия что поддерживая 2 проекта отдельными репозиториями вы через время просто не забудете добавить фичи? Та проблема, про которую вы говорите, она так же само актуальна для того подхода который вы отстаиваете
да какая по факту разница? как удобно, так и делайте. никто не мешает из одного репозитория код копировать в другой, как и мержить ветки, черрипикать изменения и все такое
разработчики же как-то это проблему решают. В больших проектах специально берут релиз-инженеров, задача которых менеджить процессы поддержания актуальных стендов по веткам в репозиториях, так что проблема вполне решаема. Отличаются только костыли, которые придется городить в каждом конкретном случае
Ищете «серебряную пулю»?
Универсальных рецептов нет, надо смотреть на проект и процессы. Но я бы в большинстве случаев смотрел в сторону неразрывной кодовой базы, а разделение логики делал через паттерны типа Стратегия или что-то типа того.
Ну ведь опенсорс рядом. Вообще проблема решаема еще и вопросом цены. И да релиз инженер все равно есть, чаще роль в команде, хотя и не звучит так гордо
У меня на проекте android и ios наьивные приложения по функционалу идентичны на 90%. Page objects те же самые, естественно отличаются локаторы элементов. Действия над этими элементами тоже идентичны для двух платформ. Если необходимо специфичное поведение для одной из платформ (свайп какой-нибудь), то как правило template method паттерн это всё что нужно. Подозреваю что для мобильных web приложений разница в поведении для платформ будет минимальна. Тесты можно создать в одной ветке репозитория для обоих платформ
testomat.io управление авто тестами