Не могу понять в чём преимущества page factory перед обычным page object.
может ктонибудь рассказать?
Отправлено 14 декабря 2015 - 13:33
Не могу понять в чём преимущества page factory перед обычным page object.
может ктонибудь рассказать?
Отправлено 14 декабря 2015 - 13:38
А в чём различия можете рассказать? :)
Page Factory -- это способ создания и инциализации объектов, реализующих шаблон проектирования Page Objects.
Поэтому сравнивать их бессмысленно, они не являются альтернативами, они не заменяют друг друга, а взаимно дополняют.
Отправлено 14 декабря 2015 - 14:00
А в чём различия можете рассказать? :)
Page Factory -- это способ создания и инциализации объектов, реализующих шаблон проектирования Page Objects.
Поэтому сравнивать их бессмысленно, они не являются альтернативами, они не заменяют друг друга, а взаимно дополняют.
это понятно. я может не правильно выразился. везде пишут что нужно использовать page factory. а смысл?
Отправлено 14 декабря 2015 - 14:08
А как Вы предлагаете инициализировать страницы-объекты?
Отправлено 14 декабря 2015 - 14:31
А как Вы предлагаете инициализировать страницы-объекты?
правильно говорят что правильно сформулированый вопрос уже наполовину ответ :) пока писал разобрался :)
Отправлено 15 декабря 2015 - 08:26
А как Вы предлагаете инициализировать страницы-объекты?
правильно говорят что правильно сформулированый вопрос уже наполовину ответ :) пока писал разобрался :)
А поделится своим пониманием? Это-ж форум, сюда не раз придут страждущие ответа, а тут вместо ответа правильный вопрос.
Отправлено 15 декабря 2015 - 10:06
А как Вы предлагаете инициализировать страницы-объекты?
правильно говорят что правильно сформулированый вопрос уже наполовину ответ :) пока писал разобрался :)
А поделится своим пониманием? Это-ж форум, сюда не раз придут страждущие ответа, а тут вместо ответа правильный вопрос.
Плюсую
Отправлено 16 декабря 2015 - 09:36
Условно.
Page Object - описывает страницы.
Например, LoginPage, SearchPage и т.д.
PageFactory - некий агрегатор, в котором все эти объекты можно собрать и инициализировать.
При этом в тестах обращение к страницам будет идти через PageFactory.
Например, вместо "loginPage.doSmth()" будет "pages.loginPage.doSmth()".
Например:
1. Можно инициализировать сразу все страницы (сразу при создании объекта PageFactory).
2. Можно добавить методы инициализирующие наборы страниц (чтобы не создавать те страницы, которые вам не нужны в конкретном тесте).
3. Можно использовать разные таймауты для разных страниц (в данном случае имею ввиду, что это также происходит в одном месте, в случае изменений - не надо будет по всему коду выискивать инициализации этой страницы, чтобы везде исправить).
4. Можно подстраивать систему под нужную версию ПО (например, если из-за изменений в интерфейса - разные Page Object для разных версий) или тестовой площадки (к примеру, если на одной из них железо хуже и скрипт идет медленнее - то при запуске на этой площадке ставить таймауты по-больше, на других - по-меньше).
И т.д.
Ключевой момент - управление всеми страницами вашего проекта из одного отдельно выделенного для этого класса.
Соответственно, если во всем вашем приложении - всего одна страница, Page Factory вероятно не нужен.
Но если страниц много - без него будет гораздо менее эффективно и удобно.
Отправлено 30 августа 2017 - 07:32
Условно.
Page Object - описывает страницы.
Например, LoginPage, SearchPage и т.д.
PageFactory - некий агрегатор, в котором все эти объекты можно собрать и инициализировать.
При этом в тестах обращение к страницам будет идти через PageFactory.
Например, вместо "loginPage.doSmth()" будет "pages.loginPage.doSmth()".
Например:
1. Можно инициализировать сразу все страницы (сразу при создании объекта PageFactory).
2. Можно добавить методы инициализирующие наборы страниц (чтобы не создавать те страницы, которые вам не нужны в конкретном тесте).
3. Можно использовать разные таймауты для разных страниц (в данном случае имею ввиду, что это также происходит в одном месте, в случае изменений - не надо будет по всему коду выискивать инициализации этой страницы, чтобы везде исправить).
4. Можно подстраивать систему под нужную версию ПО (например, если из-за изменений в интерфейса - разные Page Object для разных версий) или тестовой площадки (к примеру, если на одной из них железо хуже и скрипт идет медленнее - то при запуске на этой площадке ставить таймауты по-больше, на других - по-меньше).
И т.д.
Ключевой момент - управление всеми страницами вашего проекта из одного отдельно выделенного для этого класса.
Соответственно, если во всем вашем приложении - всего одна страница, Page Factory вероятно не нужен.
Но если страниц много - без него будет гораздо менее эффективно и удобно.
Я как-то не так себе это представлял
pages.loginPage.doSmth() - если в приложении 100 страниц, реализовывать 100 методов у класса Pages?
1. Оно как бы можно, а зачем? К тому же страницы, как правило, в конкструкторе требуют драйвер. А по ходу теста с ранее инициализированным драйвером может всякое произойти
2. Связано с п.1, снова не оч. ясно зачем
3. Спорный вопрос, насколько такая функциональность является заслугой фабрики
4. Вот с этим пунктом не поспоришь. Хотя конкретно с версиями, имхо, лучше решать проблемы за счет версионности кода, а не фабриками
Лично мое ИМХО. page factory дает преимущества:
1. лаконичность кода за счет декоратора элементов (вместо явной инициализации полей используем аннотации)
2. как и любая фабрика позволяет в случае необходимости спокойно использовать разные реализации одного интерфейса (как раз к примеру с версиями)
3. был пример, где нужно было плотно работать одновременно с двумя разными приложениями. Из-за особенностей архитектуры тестов оказалось удобнее всего пользоваться именно фабрикой, чтобы выставлять разные настройки страницам из разных приложений (не только таймауты, там много всего было).
4. Еще конкретно page factory + field decorator из коробки дают некоторые бонусы при работе с AJAX приложениями (за счет использования proxy элементов)
Отправлено 30 августа 2017 - 10:44
Я как-то не так себе это представлял
pages.loginPage.doSmth() - если в приложении 100 страниц, реализовывать 100 методов у класса Pages?
1. Оно как бы можно, а зачем? К тому же страницы, как правило, в конкструкторе требуют драйвер. А по ходу теста с ранее инициализированным драйвером может всякое произойти
2. Связано с п.1, снова не оч. ясно зачем
3. Спорный вопрос, насколько такая функциональность является заслугой фабрики
4. Вот с этим пунктом не поспоришь. Хотя конкретно с версиями, имхо, лучше решать проблемы за счет версионности кода, а не фабриками
Лично мое ИМХО. page factory дает преимущества:
1. лаконичность кода за счет декоратора элементов (вместо явной инициализации полей используем аннотации)
2. как и любая фабрика позволяет в случае необходимости спокойно использовать разные реализации одного интерфейса (как раз к примеру с версиями)
3. был пример, где нужно было плотно работать одновременно с двумя разными приложениями. Из-за особенностей архитектуры тестов оказалось удобнее всего пользоваться именно фабрикой, чтобы выставлять разные настройки страницам из разных приложений (не только таймауты, там много всего было).
4. Еще конкретно page factory + field decorator из коробки дают некоторые бонусы при работе с AJAX приложениями (за счет использования proxy элементов)
В классе Pages вообще нет специфических (привязанных к страницам) методов. Там только методы инициализации страницы (единые для всех). Все остальное - просто переменные, хранящие в себе ссылки на страницы. Да, у меня они паблики и не файналы. Может и не совсем правильно, зато добавляет гибкости.
С ранее инициализированным драйвером не может произойти ничего, что сделало бы инициализацию страниц невозможной, т.к. в конструкторе Pages передается AppManager, который выдает всем "заинтересованным" единый для всех драйвер (в т.ч. создает его заново, если с ним "вдруг" что-то "случилось").
Зачем инициализация блоками? Хотя бы за тем, что если у вас "в приложении 100 страниц", а тест использует, к примеру, лишь 5 из них - нет смысла инициализировать остальные 95.
Про разные таймауты - "заслуга фабрики" не в самих таймаутах, в а том, что все управление страницами в одном единственном месте.
Про версионность - так у меня реализовано из-за того, что тесты запускаются на разных версиях. Перекачивать много разных версий не удобно. А так - достаточно сказать, какая версия на выбранной площадке - все что нужно скрипт сам адаптирует.
По вашему п.1 - не совсем понимаю, причем тут page factory к инициализации полей аннотациями?
Отправлено 31 августа 2017 - 06:58
Я как-то не так себе это представлял
pages.loginPage.doSmth() - если в приложении 100 страниц, реализовывать 100 методов у класса Pages?
1. Оно как бы можно, а зачем? К тому же страницы, как правило, в конкструкторе требуют драйвер. А по ходу теста с ранее инициализированным драйвером может всякое произойти
2. Связано с п.1, снова не оч. ясно зачем
3. Спорный вопрос, насколько такая функциональность является заслугой фабрики
4. Вот с этим пунктом не поспоришь. Хотя конкретно с версиями, имхо, лучше решать проблемы за счет версионности кода, а не фабриками
Лично мое ИМХО. page factory дает преимущества:
1. лаконичность кода за счет декоратора элементов (вместо явной инициализации полей используем аннотации)
2. как и любая фабрика позволяет в случае необходимости спокойно использовать разные реализации одного интерфейса (как раз к примеру с версиями)
3. был пример, где нужно было плотно работать одновременно с двумя разными приложениями. Из-за особенностей архитектуры тестов оказалось удобнее всего пользоваться именно фабрикой, чтобы выставлять разные настройки страницам из разных приложений (не только таймауты, там много всего было).
4. Еще конкретно page factory + field decorator из коробки дают некоторые бонусы при работе с AJAX приложениями (за счет использования proxy элементов)
В классе Pages вообще нет специфических (привязанных к страницам) методов. Там только методы инициализации страницы (единые для всех). Все остальное - просто переменные, хранящие в себе ссылки на страницы. Да, у меня они паблики и не файналы. Может и не совсем правильно, зато добавляет гибкости.
С ранее инициализированным драйвером не может произойти ничего, что сделало бы инициализацию страниц невозможной, т.к. в конструкторе Pages передается AppManager, который выдает всем "заинтересованным" единый для всех драйвер (в т.ч. создает его заново, если с ним "вдруг" что-то "случилось").
Зачем инициализация блоками? Хотя бы за тем, что если у вас "в приложении 100 страниц", а тест использует, к примеру, лишь 5 из них - нет смысла инициализировать остальные 95.
Про разные таймауты - "заслуга фабрики" не в самих таймаутах, в а том, что все управление страницами в одном единственном месте.
Про версионность - так у меня реализовано из-за того, что тесты запускаются на разных версиях. Перекачивать много разных версий не удобно. А так - достаточно сказать, какая версия на выбранной площадке - все что нужно скрипт сам адаптирует.
По вашему п.1 - не совсем понимаю, причем тут page factory к инициализации полей аннотациями?
понятно, что нет методов страниц. Но на каждую страницу есть поле класса. В итоге если страниц 100 (а их может быть и больше), то нужно объявлять 100 полей, еще и инициализировать их. Не ясно зачем это вообще нужно. Любое приложение имеет одну точку входа (страница логина/главная страница). При возможности навигации к той или иной странице по прямой ссылке методы перехода реализуются внутри страницы либо в так называемом NavigationHelper. К чему нужен этот диспетчер всех страниц не ясно. И снова, подобный диспетчер не связан с фабрикой и page factory нигде не навязывает его использование.
У вас "ничего не может случиться" с драйвером после инициализации потому что классы страниц используют не ссылку на драйвер, а AppManager и он уже гарантирует, что ничего не случится с драйвером. Но это снова не про pagefactory. Классический pagefactory предполагает именно передачу драйвера, хотя вариант с wrapper-ом мне тоже больше нравится.
мой п1. относится к использованию метода initElements pagefactory. За счет использования аннотаций вместо driver.findElement() код выглядит красивее и понятней.
А насчет версионности, может, вам пока везет, но вообще это прямой путь к нереальному усложнению кода и невозможности его поддержки в будущем.
Отправлено 31 августа 2017 - 10:42
понятно, что нет методов страниц. Но на каждую страницу есть поле класса. В итоге если страниц 100 (а их может быть и больше), то нужно объявлять 100 полей, еще и инициализировать их. Не ясно зачем это вообще нужно. Любое приложение имеет одну точку входа (страница логина/главная страница). При возможности навигации к той или иной странице по прямой ссылке методы перехода реализуются внутри страницы либо в так называемом NavigationHelper. К чему нужен этот диспетчер всех страниц не ясно. И снова, подобный диспетчер не связан с фабрикой и page factory нигде не навязывает его использование.
У вас "ничего не может случиться" с драйвером после инициализации потому что классы страниц используют не ссылку на драйвер, а AppManager и он уже гарантирует, что ничего не случится с драйвером. Но это снова не про pagefactory. Классический pagefactory предполагает именно передачу драйвера, хотя вариант с wrapper-ом мне тоже больше нравится.
мой п1. относится к использованию метода initElements pagefactory. За счет использования аннотаций вместо driver.findElement() код выглядит красивее и понятней.
А насчет версионности, может, вам пока везет, но вообще это прямой путь к нереальному усложнению кода и невозможности его поддержки в будущем.
Про одну точку входа - весьма спорное утверждение. У меня в приложении их три, к примеру, и все разные.
Поля инициализируются один раз, когда появляется новая страница. Дальше я и про класс и его поля и думать не думаю, просто использую там, где требуется. Не понимаю, в чем проблема от их использования?
Насколько я понимаю суть паттерна (возможно я ошибаюсь) - без PageFactory, каждый раз, когда мне нужно будет использовать страницу SomePage (c аннотациями для полей/кнопок и пр.), мне нужно будет каждый раз писать new SomePage(). А если страница много где используется? Если даже хранить где-то ссылку - надо прописывать проверки: если она вдруг null - надо бы её создать, прежде чем использовать. Все это дополнительный код.
C PageFactory и единым менеджером страниц все это не нужно. В менеджере один раз вызывается initElements при создании самого менеджера (либо при инициализации набора страниц). А дальше я просто использую уже созданные cтраницы без предварительных дополнительных созданий/проверок и пр.
NavigationHelper и у меня есть. Работает он со страницами, которые получает из Pages. Зачем именно так? К примеру, у меня есть в Pages какое-то поле. Условно назовем его "тип" = ISpecialInterface. NavigationHelper - просто работает с методами, указанными в указанном интерфейсе. Его задача - просто правильная навигация по страницам проекта. Инициализация этих страниц и т.п. - уже совсем другая задача, никак не относящаяся непосредственно к навигации. И решает её как раз - менеджер страниц. Я могу в Pages поменять конструктор при инициализации страницы, подсунув другую реализацию. NavigationHelper продолжит работать как ни в чем не бывало - т.к. ему до лампочки, какая страница подсунута - он работает с интерфейсом и свою задачу продолжит исправно выполнять, даже если реализация страницы - изменится.
Это тоже один из хороших принципов (до идеала исполнения которого мне ещё далеко) - один класс = одна задача.
А про initElements - так и не поняла. У меня прекрасно используется именно initElements, при этом никакого "driver.findElement()" в нём нет, элементы на страницах все с аннотациями. Сам initElements - из класса PageFactory (селениумовский, не самописный). Аннотации и initElements без findElement'а - не связаны и не мешают.друг другу.
Не знаю насколько именно "везет", но код пишу достаточно давно и за считанные секунды легко могу переключиться между разными версиями и разными окружениями - скрипт запустится и подстроится.
Плюс это позволяет тесты добавлять заранее - даже если ни запустятся в общей куче раньше времени - ничего не случиться, если версия не изменилась пока.
В любом случае - сколько людей, столько и мнений.
Отправлено 01 сентября 2017 - 06:42
понятно, что нет методов страниц. Но на каждую страницу есть поле класса. В итоге если страниц 100 (а их может быть и больше), то нужно объявлять 100 полей, еще и инициализировать их. Не ясно зачем это вообще нужно. Любое приложение имеет одну точку входа (страница логина/главная страница). При возможности навигации к той или иной странице по прямой ссылке методы перехода реализуются внутри страницы либо в так называемом NavigationHelper. К чему нужен этот диспетчер всех страниц не ясно. И снова, подобный диспетчер не связан с фабрикой и page factory нигде не навязывает его использование.
У вас "ничего не может случиться" с драйвером после инициализации потому что классы страниц используют не ссылку на драйвер, а AppManager и он уже гарантирует, что ничего не случится с драйвером. Но это снова не про pagefactory. Классический pagefactory предполагает именно передачу драйвера, хотя вариант с wrapper-ом мне тоже больше нравится.
мой п1. относится к использованию метода initElements pagefactory. За счет использования аннотаций вместо driver.findElement() код выглядит красивее и понятней.
А насчет версионности, может, вам пока везет, но вообще это прямой путь к нереальному усложнению кода и невозможности его поддержки в будущем.
Про одну точку входа - весьма спорное утверждение. У меня в приложении их три, к примеру, и все разные.
Поля инициализируются один раз, когда появляется новая страница. Дальше я и про класс и его поля и думать не думаю, просто использую там, где требуется. Не понимаю, в чем проблема от их использования?
Насколько я понимаю суть паттерна (возможно я ошибаюсь) - без PageFactory, каждый раз, когда мне нужно будет использовать страницу SomePage (c аннотациями для полей/кнопок и пр.), мне нужно будет каждый раз писать new SomePage(). А если страница много где используется? Если даже хранить где-то ссылку - надо прописывать проверки: если она вдруг null - надо бы её создать, прежде чем использовать. Все это дополнительный код.
C PageFactory и единым менеджером страниц все это не нужно. В менеджере один раз вызывается initElements при создании самого менеджера (либо при инициализации набора страниц). А дальше я просто использую уже созданные cтраницы без предварительных дополнительных созданий/проверок и пр.
NavigationHelper и у меня есть. Работает он со страницами, которые получает из Pages. Зачем именно так? К примеру, у меня есть в Pages какое-то поле. Условно назовем его "тип" = ISpecialInterface. NavigationHelper - просто работает с методами, указанными в указанном интерфейсе. Его задача - просто правильная навигация по страницам проекта. Инициализация этих страниц и т.п. - уже совсем другая задача, никак не относящаяся непосредственно к навигации. И решает её как раз - менеджер страниц. Я могу в Pages поменять конструктор при инициализации страницы, подсунув другую реализацию. NavigationHelper продолжит работать как ни в чем не бывало - т.к. ему до лампочки, какая страница подсунута - он работает с интерфейсом и свою задачу продолжит исправно выполнять, даже если реализация страницы - изменится.
Это тоже один из хороших принципов (до идеала исполнения которого мне ещё далеко) - один класс = одна задача.
А про initElements - так и не поняла. У меня прекрасно используется именно initElements, при этом никакого "driver.findElement()" в нём нет, элементы на страницах все с аннотациями. Сам initElements - из класса PageFactory (селениумовский, не самописный). Аннотации и initElements без findElement'а - не связаны и не мешают.друг другу.
Не знаю насколько именно "везет", но код пишу достаточно давно и за считанные секунды легко могу переключиться между разными версиями и разными окружениями - скрипт запустится и подстроится.
Плюс это позволяет тесты добавлять заранее - даже если ни запустятся в общей куче раньше времени - ничего не случиться, если версия не изменилась пока.
В любом случае - сколько людей, столько и мнений.
Совершенно верно, сколько людей - столько и мнений. и у меня нет цели вас переубедить. Если вы хотите использовать менеджер страниц - ваше право.
Изначально посыл был в том, что ни менеджер страниц, ни отложенная, ни ранняя инициализация не относятся к PageFactory. Это уже исключительно элемент вашего фрэймворка. Потому не является ни плюсом ни минусом самого паттерна. Диспетчер прекрасно реализуется и без фабрики. Фабрика действительно дает преимущество с точки зрения единой точки конфигурирования и возможности подстраиваться под разные условия выполнения.
initElements конкретно в случае PageFactory является его частью и именно его использование позволяет определять элементы через аннотации. Хотя декоратор можно использовать и без фабрики.
0 пользователей, 0 гостей, 0 анонимных