testomat.io управление авто тестамиЧто за очередной бред? Какие тысячи локаторов в одном классе? у вас есть сущность у которой есть локаторы и методы, зачем вы их разделяете?
Локаторы и методы вместе в одном классе, а отделаю я их от класса с тестами. Если вам так не удобно вас никто не заставляет это использовать.
Тогда извините, неправильно понял. В тестах локаторов быть не должно, согласен.
1 лайк
Это тоже не догма.
Я использую тесты на Gherkin, и у меня иногда используется такой step:
When I click on element with xpath "//some_xpath"
Это удобно в некоторых случаях ).
Ага, а когда поменяется локатор у элемента - менять во всех степах
4 лайка
Говорю же, в некоторых случаях. Например, вызывается один раз на все features.
Да и Ctrl+h работает отлично.
Это плохо в любых случаях.
Вы уйдёте с проекта или просто в отпуск, незнакомый с кодом человек сядет фиксать упавшие тесты, и ему придётся тратить время, чтобы понять, что это за элемент такой. Один раз он у вас в коде или много. Да и просто читаемость тестов с локаторами ниже, чем без них. Бизнес аналитики и продукт оунеры тоже будут не рады, если им придётся в ваши тесты лезть.
Это gherkin. В названии сценарии например может быть написано условно “Проверяю нажатие на кнопку Х”.
Локатор в степе этого сценария явно укажет на xpath этой кнопки.
Говорю же, “иногда”. Иногда это маленький тест, и можно быстро накидать сценарии с этим шагом
Это не догма. Это не закон. Иногда надо быть гибче. Хотя, зачем я кому-то что-то доказываю.
Вы ничего и не пытались доказать.
Фактов нету
Доводы есть.
Использовать глагол “доказывать” имел право.
Тесты бывают разные. В моей ситуации, а она может быть у любого, использование локатора в самом тесте было удобным, хотя это конечно некрасивое решение.
Судите сами, тест с таким универсальным шагом пишется очень быстро. Исправлять - не сложно, если упадет, так как из сценария понятно, какой элемент ищется. Если бы на каждый такой тест я бы лез в page, это было бы дольше, page рос бы неоправданно. Потому однозначно утверждать, что локаторам не место в тестах - нельзя.
1 лайк
Ваш подход к Page object отношения совсем не имеет. Поэтому давайте прекратим флудить не по теме, и на этом разойдемся. Спасибо.
Я прекратил обсуждение и ушел из темы. Но кое кто решил продолжить.
Да. Давайте перестанем флудить.
Спасибо.
Так же само - если страница используется больше чем одним тестом - делаю пэйджобджект, если на страницу 1 тест заходит 1 раз - пишу прямые локаторы.
1 лайк
Доброго времени суток, автор мне так кажется столкнулся с реализацией под несколько окружении, когда таким образом можно вынести локаторы для андроида и иос в один класс или xml, для веб и ром модели нормой считается один класс для модели страницы, и логикой, а второй для тестов. Но тут ещё есть бейс модели где можно хранить вещи для всех страниц или бейс тест класс для метастепов, например логин
К сожалению, вам кажется, у автора веб проект.
Одна из проблем, с который мы уже столкнулись при использовании этого подхода с разделением, это невозможность наследования класса страницы от класса BasePage, где мы храним общие для всех страниц методы. Мы пишем на C#, множественного наследования здесь нет, а т.к. страница наследует локаторы, то место уже занято.
Немного расскажу, как в моем проекте. Тоже пишу на С#, используем BDD - SpecFlow.
Весь проект разделен на папки - PageObjects, Steps, Utils, Features. Все Page objects хранятся в одноименной папке, для каждой страницы сайта свой класс, который содержит веб элементы для данной страницы и некоторые методы, которые задействуют больше одного веб элемента. Есть отдельный класс для общих элементов - которые используются на более чем одной странице. Для каждого Page object класса есть свой Steps класс - содержит действия, шаги для работы с веб элементами своего Page object’a. Есть еще класс Utils, он содержит Extensions - методы для работы с веб элементами.
1 лайк