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

Оправдано ли использование PageObject паттерна

В последнее время просматривал свои тесты и пришел к выводу что они немного неэстетичны. решил порефакторить. Полистал информацию по PageObject паттерну, с виду все понравилось. попробовал написать небольшой пробный каркас. Написал - понравился вид кода. теперь сижу и думаю, стоит ли строить новый фреймворк и переводить 2-3 десятка тестов под него, учитывая то что разработка фреймворка займет несколько недель.

 

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

из минусов: как по мне весьма длительная переработка тестов.

какие еще плюсы и минусы есть у данного паттерна?

 

З.Ы. может все таки стоит прислушатся к старому анекдоту:

Сидит программист глубоко в отладке.
Подходит сынишка:
- Папа, почему солнышко каждый день встает на востоке, а садится на западе?
- Ты это проверял?
- Проверял.
- Хорошо проверял?
- Хорошо.
- Работает?
- Работает.
- Каждый день работает?
- Да, каждый день.
- Тогда ради бога, сынок, ничего не трогай, ничего не меняй.

1 Симпатия

Я могу Вам скинуть свою презентацию по качественному построению фреймворка на основе Page Object, - ета практика реально хороша)

елси нужно приатачю.

Очень было бы интересно почитать

было бы неплохо посмотреть.

киньте почти свои)

там как би рисунками все, но по рисункам андерстендабилити норм))

просмотрел презентацию. несовсем ясна роль pageLoader синглтона.

в классе pageloader реализировани getinstance-и всех телзов автоматизации, например WebDriver Driver, Sikuli object , etc - что и дает понятие синглтона

хм.. я сделал точно то же самое но без синглтона, а просто сделал базовый класс Page, в котором инициализируются все общие переменные: драйвера, etc.

 

еще меня немного смущает такая вещь, допустим в процессе теста мне нужно пройтись по трём десяткам страниц, а для этого мне нужно каждый раз делать конструкцию типа: SomePage page= SomeMethodWhoReturnSomePage(); SomePage2=page.someMethodWhoReturnSomePage2(); и так далее. выходит что многовато переменных заводить.

вашу проблему как раз решает реализация фактори паттерна, поищите здесь на форуме, тут мы писали об этом.

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

Да не за что, обращайтесь.

Тоесть у вас получаеться динамически дерево вашего ресурса на 120-150 страниц разелено отдельно при переключениях, я правильно понимаю ???

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

выложи плиз где-то публично, чтобы все могли посмотреть

я ее доделаю и на какой то онлайн сайт по перезенташках повешу) 

ну можно и так сказать. я пробую сделать как по учебнику. класс страницы, при вызове методов которые ведут на другую страницу, методы возвращают обьект той страницы, куда они ведут. и так далее. все поля страниц инициализируются через PageFactory.initElements, и хранятся в переменных типа @FindBy(name = locator) private Webelement element; а локаторы лежат в виде констант в интерфейсах которые реализуются соответствующими страницами.

 

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

slideshare.net

thank you, туда и залью)

ждем ссылочки

Можно ссылочку пожалуйста? Поглядеть хотя бы одним глазком :slight_smile:

А можете мне выслать тоже? Спасибо.