либо называть кнопку по своей бизнесовой сути, но в аннотации к методу с ней IDE будет подсказывать инстанс возвращаемой пейджи

договориться можно как угодно. и имплементировать как хочется :) я не вижу разницы возвращать ссылку из класса или создавать в тесте

ну разве что в диффе коммита нагляднее читать измененную логику теста, а не измененную логику двух пейджов в разных файлах

а вот тут пример бы , потому что не совсем понятно что поменялось на сайте

ну раз тема про другие страницы, то допустим, изменился переход другую страницу мобильного приложения. ну так получилось. соответственно, было “клик_эту_кнопка() -> view1” стало “клик_эту_кнопка() -> view2”. в общем в диффе будет так же все понятно ?ох. ну значит нет разницы

> возвращать ссылку из класса Это как? Приведи код

страница1: def клик_эту_кнопка(): return new страница2() страница2: … страница2 = страница1.клик_эту_кнопка()

или альтернативный вариант

страница1: def клик_эту_кнопка(): …. страница2: … страница1.клик_эту_кнопка() страница2 = new страница2()

это типа # method 1, somewhere in the test smarphones_page.add_do_cart(model_title='iphone 7s') smartphones_page.go_to_cart() cart = CartPage() # явно определяем переход на новую старницу, виджет, етс cart.proceed_with_payment() # method 2, somewhere in the test smarphones_page.add_do_cart(model_title='iphone 7s') cart = smartphones_page.go_to_cart() cart.proceed_with_payment()потому что где-то в есть код: # smartphones_page.py def go_to_cart(self): get_element(CART_BTN).click() return CartPage(driver=self.driver) # передаем в переменную другой инстанс пейджи

method 1 менее читаемый. Кто вообще глядя на этот код свяжет что smartphones_page.go_to_cart() и cart = CartPage() как-то взаимосвязаны?

Между этими двумя строчками понапихают каких-нибудь хелперов и логика окончательно разъедется.

+ во втором методе можно доп. ассерты навесить в метод go_to_cart на создаваемую страницу, если оно потребуется.

?

во втором методе создаваемой страницы уже должны быть софт ассерты в конструкторе класса

с другой стороны. ассертить другую cart страницу в методе smartphones_page?

так вот да. ассерт себя в конструкторе себя - логично. ассерт другой страницы в чужом классе - как-то так

нет, это не обязательно, как только ты вернул инстанс другой страницы - на это ответственность одного пейдж объекта заканчивается и начинается ответственность другого

во втором методе создаваемой страницы уже должны быть софт ассерты в конструкторе класса

Ну это инварианты, которые верны всегда для CartPage. А вдруг надо будет сделать специфичный инвариант именно при переходе с smarpthones_page на CartPage

Ну это инварианты, которые верны всегда для CartPage. А вдруг надо будет сделать специфичный инвариант именно при переходе с smarpthones_page на CartPage

тогда ты будешь возвращать не чисто пейджу, а пейдж фэктори :) которая сама будет решать по твоим входным данным какие инварианты нужно тестировать

то бишь это будешь возвращаться некая Abstarct factory решающая какие страницы возвращать.

Ну не, фактори это слишком сложно. А тут всегда возвращается одна и та же страница, просто еще у нее проверяется пара специфичных условий.

хм ну тогда 3 варианта 1) ассертить следующую страницу и возвращать объект из метода 2) не ассертить, но возвращать объект из метода. ассертить в тесте перед следующими шагами 3) не возвращать ничего. инициализировать объект в тесте и ассертить в конструкторе

Это зародыш фактори.

Ну не, фактори это слишком сложно. А тут всегда возвращается одна и та же страница, просто еще у нее проверяется пара специфичных условий.

передавать в конструктор пейджи маячок-контекста, который будет по свич-кейсу где-то нужную логику чекать

хм ну тогда 3 варианта 1) ассертить следующую страницу и возвращать объект из метода 2) не ассертить, но возвращать объект из метода. ассертить в тесте перед следующими шагами 3) не возвращать ничего. инициализировать объект в тесте и ассертить в конструкторе

Да, все эти 3 варианта могут быть в разных тестах наиболее подходящими.

например аргумент went_from='iphone_page' где в конструкторе будут находится блоки софт ассертов на каждый вариант контекстов, которые нужно проверять

Если сложный случай с кучей кейсов то да, фабрика и нужна будет.

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

И опять же этот вызов фабрики легче сделать в методе go_to_cart(

А с new придется кучу мест править.

по большому счету без разницы в какой из пейдж это будет, главное, чтобы не в тесте :)

dry, и ты в порядке

> можно так же просто в теле теста сделать. или в методе и через аргумент. Это не равноценно. Если у тебя 100500 тестов и в каждом проверяется независимо ассерт, то при изменении требований тебе надо будет исправить 100500 строк.

А в случае когда все инкапсулировано в метод/фабрику - в одном месте переписать.

> без сказочных условий Вся инженерия ПО и борется с этими постоянно меняющимися сказочными условиями. Иначе все бы писали в процедурном стиле 1 раз и никаких тестов на код не надо было бы вообще.

И паттернов никаких не придумывали бы.

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

с точки зрения удобства когда все внезапно поменялось - мне удобнее ревью 1 файл. а не 10, на разные пейджы

то есть файл с бизнес логикой теста

или если перефразировать. в случае когда все поменялось и ассерты внутри страниц, то поменяется и сам тест, и ассерты. когда странцы инициализируются в тесте - поменяются только тесты

пейджы могут годами не меняться, но логика их переключения да

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

пейджы могут годами не меняться, но логика их переключения да

скорее тесты не должны меняться, потому что они как раз и переиспользуются

это какой-то рак теста, если есть пейджи, но ты в них не меняешь реализацию внутри методов

Бгг

у тебя есть 1000 тестов, которые каким-то образом попадали на карт. Ты НЕ захочешь менять это в 1000 тестов. Как ты хочешь это сделать? иметь метод go_to_cart и поменять только его

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

Или идешь и добавляешь ассерты в 100500 тестов, а потом идешь в окно.

ну, Паша то же самое повторил :)

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

Тут лучше либо в метод-прослойку, либо фабрика, ну или на худой конец отнаследоваться от пейдж обжекта и реализовывать в каждом конструктуре свои ассерты. Но это сложновато.

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

что значит "конструктор на всю систему один". Бог даровал наследование и оверрайд методов суперкласса. Куча конструкторов для каждой пейджи.

По последним трендам наследование это антипаттерн.

лол

Но в целом да, удобно :)

я не говорю про х10 Inception наследования, каким был графический кит при разработке под windows, (можно почитать в книге Банды четырех). С пейджами хватает максимум 2х суперклассов, больше я не встречал. Помогало выстроить набор софт ассертов в конструкторах на все случаи жизни

Здравствуйте! Насколько актуально сейчас изучать автоматизацию на C# ?

Для каких-то проектов, где исользуется си шарп - актуально. Для каких-то, где не используется - нет.

Для каких-то проектов, где исользуется си шарп - актуально. Для каких-то, где не используется - нет.

Получается, что желательно все языки знать в определенном части. Что это за часть? Или я не прав?

Эээ... Что?

Я имел ввиду, что если у вас в компании используется до диез в стеке технологий для автоматизации - то учите и это будет полезно. А если питон, руби или джава, то зачем?

Если просто "нужно что то изучать" то смотри в сторону python и java

Если просто "нужно что то изучать" то смотри в сторону python и java

у Java есть преимущества перед python в QA кроме большего количества кода? :))

что лучше, веник или метла?

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

у Java есть преимущества перед python в QA кроме большего количества кода? :))

Статическая типизация

Статическая типизация

это преимущество?

Ну буду начинать холивар, каждый видит своё

что лучше, веник или метла?

Многие говорят начинай с метлы, с веником после легко справишься))

Мозг говорит бери метлу, а сердце тянется к венику))

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

По поводу порога вхождения спорно. Для написания простых автотестов нужно знать минимум что там что там)

какая разница на чем говнокодить?)

хоть на ассемблере

а если тестирование мобильное?

ответ тот же

под апиум есть куча клиентских либ

вроде даже js

у Java есть преимущества перед python в QA кроме большего количества кода? :))

да

под апиум есть куча клиентских либ

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

не сталкивался ни с одной из этих проблем. Аппиум на андроид работает шикарно. С iOS есть траблы да, но вот андроид прям конфетка

Как многопоток может влиять на UI тесты я вообще смутно понимаю

А переключение между процессами(точнее активити в разных процессах) работает отлично

к cлову об аппиумах. кто-нибудь тестирует reactnative на андроиде через последний релиз appium-uiautomator2? в предыдущей версии elemet id были не доступны. собственно вопрос - проблема решена?

Всем привет. Есть вопрос. Запускаем автоматизацию на проекте и надо произвести выбор средств для автоматизации. Вроде как все остальное нашел как обойти но с этим проблемы. Задача только тестирование iOS версии. Как вы автоматизировали тестирование in-app на iOS? Буду благодарен если посоветуете как решить эту проблему.

Всем привет. Есть вопрос. Запускаем автоматизацию на проекте и надо произвести выбор средств для автоматизации. Вроде как все остальное нашел как обойти но с этим проблемы. Задача только тестирование iOS версии. Как вы автоматизировали тестирование in-app на iOS? Буду благодарен если посоветуете как решить эту проблему.

Под in-app вы подразумеваете in-app purchasы или что-то другое?

Извиняюсь, да именно in-app purchase

https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnectInAppPurchase_Guide/Chapters/TestingInAppPurchases.html http://help.testlio.com/testing-mobile-applications/testing-in-app-purchases-on-ios https://support.magplus.com/hc/en-us/articles/203809008-iOS-How-to-Test-In-App-Purchases-in-Your-App

Ну и всё прочее с первой страницы поисковой выдачи :)

Или есть какие-то более конкретные проблемы?

да как проверить ручками я знаю. Подскажите как то же самое сделать например через Appium, XCUItest и т.д.