Перейти к содержимому

Фотография

page factory


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 12

#1 lapa

lapa

    Новый участник

  • Members
  • Pip
  • 55 сообщений


Отправлено 14 декабря 2015 - 13:33

Не могу понять в чём преимущества page factory перед обычным page object.

может ктонибудь рассказать?


  • 0

#2 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 14 декабря 2015 - 13:38

А в чём различия можете рассказать? :)

 

Page Factory -- это способ создания и инциализации объектов, реализующих шаблон проектирования Page Objects.

 

Поэтому сравнивать их бессмысленно, они не являются альтернативами, они не заменяют друг друга, а взаимно дополняют.


  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#3 lapa

lapa

    Новый участник

  • Members
  • Pip
  • 55 сообщений


Отправлено 14 декабря 2015 - 14:00

А в чём различия можете рассказать? :)

 

Page Factory -- это способ создания и инциализации объектов, реализующих шаблон проектирования Page Objects.

 

Поэтому сравнивать их бессмысленно, они не являются альтернативами, они не заменяют друг друга, а взаимно дополняют.

это понятно. я может не правильно выразился. везде пишут что нужно использовать page factory. а смысл?


  • 0

#4 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 14 декабря 2015 - 14:08

А как Вы предлагаете инициализировать страницы-объекты?


  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#5 lapa

lapa

    Новый участник

  • Members
  • Pip
  • 55 сообщений


Отправлено 14 декабря 2015 - 14:31

А как Вы предлагаете инициализировать страницы-объекты?

правильно говорят что правильно сформулированый вопрос уже наполовину ответ :) пока писал разобрался :)


  • 0

#6 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 15 декабря 2015 - 08:26

 

А как Вы предлагаете инициализировать страницы-объекты?

правильно говорят что правильно сформулированый вопрос уже наполовину ответ :) пока писал разобрался :)

 

А поделится своим пониманием? Это-ж форум, сюда не раз придут страждущие ответа, а тут вместо ответа правильный вопрос.


  • 1

#7 Alekssh1ft

Alekssh1ft

    Новый участник

  • Members
  • Pip
  • 30 сообщений


Отправлено 15 декабря 2015 - 10:06

 

 

А как Вы предлагаете инициализировать страницы-объекты?

правильно говорят что правильно сформулированый вопрос уже наполовину ответ :) пока писал разобрался :)

 

А поделится своим пониманием? Это-ж форум, сюда не раз придут страждущие ответа, а тут вместо ответа правильный вопрос.

 

Плюсую


  • 0

#8 TatyanaV

TatyanaV

    Опытный участник

  • Members
  • PipPipPipPip
  • 388 сообщений
  • ФИО:Воробьева Татьяна


Отправлено 16 декабря 2015 - 09:36

Условно.

Page Object - описывает страницы.

Например, LoginPage, SearchPage и т.д.

PageFactory - некий агрегатор, в котором все эти объекты можно собрать и инициализировать.

 

При этом в тестах обращение к страницам будет идти через PageFactory.

Например, вместо "loginPage.doSmth()" будет "pages.loginPage.doSmth()".

 

Например:

1. Можно инициализировать сразу все страницы (сразу при создании объекта PageFactory).

2. Можно добавить методы инициализирующие наборы страниц (чтобы не создавать те страницы, которые вам не нужны в конкретном тесте).

3. Можно использовать разные таймауты для разных страниц (в данном случае имею ввиду, что это также происходит в одном месте, в случае изменений - не надо будет по всему коду выискивать инициализации этой страницы, чтобы везде исправить).

4. Можно подстраивать систему под нужную версию ПО (например, если из-за изменений в интерфейса - разные Page Object для разных версий) или тестовой площадки (к примеру, если на одной из них железо хуже и скрипт идет медленнее - то при запуске на этой площадке ставить таймауты по-больше, на других - по-меньше).

И т.д.

 

Ключевой момент - управление всеми страницами вашего проекта из одного отдельно выделенного для этого класса.

Соответственно, если во всем вашем приложении - всего одна страница, Page Factory вероятно не нужен.

Но если страниц много - без него будет гораздо менее эффективно и удобно.


  • 0

#9 Alex

Alex

    Постоянный участник

  • Members
  • PipPipPip
  • 237 сообщений
  • ФИО:Алексей

Отправлено 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 элементов)


  • 0

#10 TatyanaV

TatyanaV

    Опытный участник

  • Members
  • PipPipPipPip
  • 388 сообщений
  • ФИО:Воробьева Татьяна


Отправлено 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 к инициализации полей аннотациями? 


  • 0

#11 Alex

Alex

    Постоянный участник

  • Members
  • PipPipPip
  • 237 сообщений
  • ФИО:Алексей

Отправлено 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() код выглядит красивее и понятней.

А насчет версионности, может, вам пока везет, но вообще это прямой путь к нереальному усложнению кода  и невозможности его поддержки в будущем.


  • 0

#12 TatyanaV

TatyanaV

    Опытный участник

  • Members
  • PipPipPipPip
  • 388 сообщений
  • ФИО:Воробьева Татьяна


Отправлено 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'а - не связаны и не мешают.друг другу.

 

Не знаю насколько именно "везет", но код пишу достаточно давно и за считанные секунды легко могу переключиться между разными версиями и разными окружениями - скрипт запустится и подстроится.

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

 

В любом случае - сколько людей, столько и мнений. 


  • 0

#13 Alex

Alex

    Постоянный участник

  • Members
  • PipPipPip
  • 237 сообщений
  • ФИО:Алексей

Отправлено 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 пользователей, 0 гостей, 0 анонимных