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

webdriver
#1

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

 

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

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

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

 

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

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

1 лайк
#2

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

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

#3

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

#4

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

#5

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

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

#6

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

#7

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

#8

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

 

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

#9

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

#10

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

#11

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

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

#12

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

#13

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

#14

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

#15

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

 

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

#16

slideshare.net

#17

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

#18

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

#19

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

#20

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