Разные подходы к Page object паттерну и где лучше хранить локаторы

design-patterns
locators
page-object
Теги: #<Tag:0x00007f7b63d2e0c0> #<Tag:0x00007f7b63d2ddf0> #<Tag:0x00007f7b63d2d940>

(Oleksii Ihnatiuk) #21

Что за очередной бред? Какие тысячи локаторов в одном классе? у вас есть сущность у которой есть локаторы и методы, зачем вы их разделяете?


(Fiodar Motin) #22

Локаторы и методы вместе в одном классе, а отделаю я их от класса с тестами. Если вам так не удобно вас никто не заставляет это использовать.


(Oleksii Ihnatiuk) #23

Тогда извините, неправильно понял. В тестах локаторов быть не должно, согласен.


(Bolatbek) #24

Это тоже не догма.
Я использую тесты на Gherkin, и у меня иногда используется такой step:

When I click on element with xpath "//some_xpath"

Это удобно в некоторых случаях ).


(Maxim Andryushchenkov) #25

Ага, а когда поменяется локатор у элемента - менять во всех степах


(Bolatbek) #26

Говорю же, в некоторых случаях. Например, вызывается один раз на все features.
Да и Ctrl+h работает отлично.


(Эллина Кулагина) #27

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


(Bolatbek) #28

Это gherkin. В названии сценарии например может быть написано условно “Проверяю нажатие на кнопку Х”.
Локатор в степе этого сценария явно укажет на xpath этой кнопки.
Говорю же, “иногда”. Иногда это маленький тест, и можно быстро накидать сценарии с этим шагом


(vmaximv) #29


(Bolatbek) #30

Это не догма. Это не закон. Иногда надо быть гибче. Хотя, зачем я кому-то что-то доказываю.


(vmaximv) #31

Вы ничего и не пытались доказать.


(Bolatbek) #32

Ну, раз такая пляска.

https://ru.m.wiktionary.org/wiki/доказывать

Доводы я привел? Привёл.


(vmaximv) #33

Фактов нету


(Bolatbek) #34

Доводы есть.
Использовать глагол “доказывать” имел право.

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


(Эллина Кулагина) #35

Ваш подход к Page object отношения совсем не имеет. Поэтому давайте прекратим флудить не по теме, и на этом разойдемся. Спасибо.


(Bolatbek) #36

Я прекратил обсуждение и ушел из темы. Но кое кто решил продолжить.
Да. Давайте перестанем флудить.

Спасибо.


#37

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


(Максим) #38

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


(Эллина Кулагина) #39

К сожалению, вам кажется, у автора веб проект.
Одна из проблем, с который мы уже столкнулись при использовании этого подхода с разделением, это невозможность наследования класса страницы от класса BasePage, где мы храним общие для всех страниц методы. Мы пишем на C#, множественного наследования здесь нет, а т.к. страница наследует локаторы, то место уже занято.


(Valentin G ) #40

Немного расскажу, как в моем проекте. Тоже пишу на С#, используем BDD - SpecFlow.
Весь проект разделен на папки - PageObjects, Steps, Utils, Features. Все Page objects хранятся в одноименной папке, для каждой страницы сайта свой класс, который содержит веб элементы для данной страницы и некоторые методы, которые задействуют больше одного веб элемента. Есть отдельный класс для общих элементов - которые используются на более чем одной странице. Для каждого Page object класса есть свой Steps класс - содержит действия, шаги для работы с веб элементами своего Page object’a. Есть еще класс Utils, он содержит Extensions - методы для работы с веб элементами.