В последнее время просматривал свои тесты и пришел к выводу что они немного неэстетичны. решил порефакторить. Полистал информацию по PageObject паттерну, с виду все понравилось. попробовал написать небольшой пробный каркас. Написал - понравился вид кода. теперь сижу и думаю, стоит ли строить новый фреймворк и переводить 2-3 десятка тестов под него, учитывая то что разработка фреймворка займет несколько недель.
из плюсов вижу: удобночитаемый и удобноподдерживаемый код, рефакторинг существующих тестов(немного набрался опыта и имею новое видение структуры).
из минусов: как по мне весьма длительная переработка тестов.
какие еще плюсы и минусы есть у данного паттерна?
З.Ы. может все таки стоит прислушатся к старому анекдоту:
Сидит программист глубоко в отладке. Подходит сынишка: - Папа, почему солнышко каждый день встает на востоке, а садится на западе? - Ты это проверял? - Проверял. - Хорошо проверял? - Хорошо. - Работает? - Работает. - Каждый день работает? - Да, каждый день. - Тогда ради бога, сынок, ничего не трогай, ничего не меняй.
в классе pageloader реализировани getinstance-и всех телзов автоматизации, например WebDriver Driver, Sikuli object , etc - что и дает понятие синглтона
хм.. я сделал точно то же самое но без синглтона, а просто сделал базовый класс Page, в котором инициализируются все общие переменные: драйвера, etc.
еще меня немного смущает такая вещь, допустим в процессе теста мне нужно пройтись по трём десяткам страниц, а для этого мне нужно каждый раз делать конструкцию типа: SomePage page= SomeMethodWhoReturnSomePage(); SomePage2=page.someMethodWhoReturnSomePage2(); и так далее. выходит что многовато переменных заводить.
нашел. в принципе, похожие идеи меня посещали, но я над ними еще в раздумиях, у меня намечается покрытие всего приложения обьектами страниц, а это примерно 120-150 классов. в любом случае спасибо.
более чем оправдана, весь мир этим паттерном пользуется и все довольны! а на счет изменений, наоборот, я вам рекомендую менять и рефакторить ваш код может быть не весь сразу когда, а постепенно, но делать это нужно. на анектод не смотрите, все равно время не поддержку тестов надо уменьшать, а с PageObject паттерном это легко и быстро
ну можно и так сказать. я пробую сделать как по учебнику. класс страницы, при вызове методов которые ведут на другую страницу, методы возвращают обьект той страницы, куда они ведут. и так далее. все поля страниц инициализируются через PageFactory.initElements, и хранятся в переменных типа @FindBy(name = locator) private Webelement element; а локаторы лежат в виде констант в интерфейсах которые реализуются соответствующими страницами.
таким образом я пытаюсь выделить хранилище для локаторов, определить на каждой странице элементы, и реализовать методы для каждой из страниц.