Несколько советов по созданию page object классов здорового человека Хабр

Итак, в этом примере мы создадим класс с именем LoginPage. Это начало нового года, и многие люди во всем мире принимают решение уделять больше внимания своему здоровью. На самом деле, ваши тесты для фронтенда также нуждаются в таком решении. Тестирование HTML5 веб приложений 6.1.Автоматизация Canvas элементов. Прежде чем мы перейдем к сути вопроса, я хотел бы сделать шаг назад для людей, которые только начали знакомятся с тестированием, и прояснить некоторые из жаргонов, которые важны в этом контексте.

Самым популярным паттерном проектирования, используемым в кодовых базах тестирования веб-UI, является паттерн Page Object Model . Этот паттерн предполагает моделирование класса для представления одной страницы тестируемой системы. На основе этой модели, класс будет содержать свойства, которые представляют элементы страницы пользовательского интерфейса и методы, которые взаимодействуют с этими элементами.

Централизованные локаторы чаще всего создают больше сложностей, чем того стоят. Более реалистичный, но не менее коварный пример — когда объекты страницы обращаются к какому-либо типу глобального состояния, чтобы получить тестовые данные (данные для входа в систему и т.д.). Объект страницы не решает напрямую, что делать, но он «звонит другу», чтобы получить эту информацию. Еще один распространенный, но часто сомнительный пример наследования в классах объектов страниц — создание базовых классов для страниц, которые очень похожи, но имеют разные локаторы. Например, страница SearchResultsPage, которая была локализована на английский, французский и немецкий языки. Мы видели несколько умных применений наследования в дизайне страничных объектов.

Здоровый код предшествует здоровым тестам

Этот метод может принимать аргументы, чтобы дать тесту немного больше контроля, но идея понятна. В противном случае они являются просто раздутыми страничными объектами. Это понимание паттернов проектирования не диктует каждую деталь ваших страничных объектов. Вот почему автоматизация тестирования требует критического и творческого мышления, свойственного разработке программного обеспечения, и не является шаблонной.

Это не имеет ничего общего с объектами страницы – просто имеет смысл хранить тестовые функции, такие как sign_in , доступным более глобально, чем через объект страницы. Каждый объект страницы будет содержать множество локаторов для соответствующих элементов на этой странице. Видя все локаторы на всех страницах, возникает соблазн собрать эти локаторы в некий централизованный класс Locators, и ссылается на него в каждом Page Object. Создавайте простые для понимания и полезные интерфейсы страничных объектов для целого ряда тестов, которые позволят следующему разработчику быстро и эффективно создавать новые тесты.

В основном вы можете не открывать браузер самостоятельно, чтобы тестировать этот материал вручную большую часть времени, что не только менее изящно, но и намного более трудоемко и подвержено ошибкам. Без этого инструмента процесс «наружного тестирования», который вы передадите из высокоуровневых тестов в свои юнит тесты, будет намного более болезненным и, возможно, поэтому будет игнорироваться. Вместо доступа к функциям через страницу это можно делать через компоненты. MobileLoginDecorator переписывает базовую функциональность логина новым классом, специфичным для мобильных устройств. Он тоже просто выводит “Mobile login” в командную строку – это сделано, чтобы сократить пример. BasicLoginComponent содержит конкретное внедрение метода логина.

Не уникальные выносятся в файл/модуль страниц, откуда потом импортируются. Начнем с того что page object – это уже некий паттерн. Второе, паттерны, уместны тогда, когда система, которую они описывают, является автоматизация тестирования при разработке продукта прозрачной и однозначной для описания, а не “живой и не состоявшейся”. Для чекбокс-элементов (или других переключателей) простое нажатие на них может не соответствовать желаемому замыслу теста.

Page Objects и наследование

Акторы объединяют действия между объектами страницы, чтобы представить эти общие агрегированные действия на страницах в виде многократно используемых фрагментов. Они обеспечивают интерфейс более высокого уровня для тестов. Таким образом, каждому тесту не нужно заново реализовывать эту последовательность, он просто использует интерфейс, предоставляемый актором. Этот пример может выглядеть простым и легко читаемым, но это всего лишь несколько основных шагов. В реальном user journey тесте, которое использует объекты страницы, раскрывающие столь детальный интерфейс, могут быть сотни отдельных шагов.

• Автоматизаторы видят кучу повторяющихся шагов в куче тестов, создают «помощника», который собирает эти шаги в одном месте, и используют этого помощника.
• Не уникальные выносятся в файл/модуль страниц, откуда потом импортируются.
• Эти названия взаимозаменяемы, и я видел, как этот паттерн называли по-разному, но независимо от названия все они служат одной цели.
• На мой взгляд, это делает еще более значимым DRY для этих спецификаций и далает их выразительными, при добавлении нескольких Ruby классов.

Если у вас схожие требования, то вам может пригодиться паттерн “декоратор”. С его помощью можно упаковать компоненты в “конверты”, которые переписывают или поддерживают лишь определенные функции. Вам не нужно писать новый класс для каждой новой характеристики компонента – внедрять нужно только изменения. Эту технику также можно использовать, если веб-компоненты меняются в зависимости от размера браузера или типа устройства. DRY — Don’t Repeat Yourself (Не повторяйся) — это общий принцип, используемый при разработке программного обеспечения.

Паттерн Page Object

Данный шаблон проектирования помогает инкапсулировать работу с отдельными элементами страницы, что позволяет уменьшить количество кода и упростить его поддержку. Если, к примеру, дизайн одной из страниц изменён, то нам нужно будет переписать только соответствующий класс, описывающий эту страницу. Данный шаблон проектирования помогает инкапсулировать работу с отдельными элементами страницы, что позволяет уменьшить количество кода и его поддержку. В абстрактный класс BasePage вы выносите методы, которые дублируются у вас на страницах, например метод клик, который вы хотите переписать с умным ожиданием. Вторая реализация с использованием объекта accountDescriptor создает более высокую связанность между классом теста и классом объекта страницы. Хотя сбор одинаковых вещей, которые изменяются вместе, является целью любого проектирования программного обеспечения, эта стратегия заходит слишком далеко.

В этом примере страница FrenchSearchResultsPage будет наследоваться от BaseSearchResultsPage. BaseSearchResultsPage определяет интерфейс, используемый каждой SearchResultsPage, и реализует все методы, на которые не влияет локализация. Затем каждая страница для конкретного языка будет реализовывать специфические для нее методы. Однако большинство современных веб-приложений не строятся как набор уникальных страниц.

Несколько советов по созданию page object классов здорового человека

— централизованно обрабатывать эксепшены для каких-то экшенов (что актуально для Selenium, когда тебе нужно дождаться какого-либо изменения на странице и только потом идти дальше). Разработку программного обеспечения легко изучить, но трудно освоить, и это часть того, что делает ее такой увлекательной. Строка ShopperActor.logonAndSelectItem(); говорит мне именно то, что мне нужно знать, чтобы понять, что делает тест.

Page Factory

На самом деле вам нужен еще более высокий уровень абстракции, который фактически охватывает объекты страницы. Шаблон Page Object Model изолирует несколько типов изменений, самым значительным и очевидным из которых является интерфейс между кодом вашеих тестов и DOM приложения. Тесты пользовательского интерфейса должны содержать информацию о том, как находить элементы на страницах. Эта информация имеет тенденцию меняться, и она имеет тенденцию меняться на разных страницах. Когда вы пишете свои функциональные спеки, вы получаете стратегию для извлечения поведения, которое проходит через тестовый флоу. Для повышения качества кода вы хотите захватить взаимодействие с определенными наборами элементов на ваших страницах, особенно если вы натыкаетесь на повторяющиеся шаблоны.

Эти тесты интерактивные показывают, что ваши компоненты работают в гармонии, когда они собраны вместе. Это разные сущности, в базовом классе пейджей – должно хранится что-то общее для пейджей, а в базовом классе тестов (от которого наследуются тесты) – должно быть что-то общее для тестов. Я скажу вам по секрету – не существует такого паттерна Page Object впринципе, это просто прямой результат, когда детали реализации отделяются от тестов. Что ты перенести понятия “тест” и “страница”, которые при данной реализации существуют исключительно в вашей голове, в код.

Вместо этого просто верните состояние и позвольте тесту определить, что оно означает. Целью POM классов является установка и получение состояния вашего приложения.Так что вам понадобятся соответствующие методы для этого. В большом проекте много страниц и они связаны между собой, для того чтобы выполнять переход добавим следующий шаг в default метод класса RegistrationPage — LoginPage.new.

Не существует единственно правильного ответа на вопрос о том, как следует строить интерфейсы между объектами и потребителями вашей страницы. Однако, поймите, что если вы создаете значительное количество таких промежуточных объектов, они по своей природе связывают вместе тесты и объекты страницы. Это может создать дополнительную работу, https://deveducation.com/ когда одна из сторон этой связи должна измениться. В большом веб-приложении могут быть сотни различных компонентов и несколько компонентов, связанных с результатами поиска. В приведенном выше примере автоматизатору не нужно искать нужный компонент, он сразу знает, что это компонент, присоединенный к странице SearchResultsPage.

Все наши выверты в построении архитектуры для тестов делаются не только для того, чтобы уменьшить дублирование кода, мы инкапсулируем логику в классах по целям, для которых они создаются. Сейчас вы не понимаете данный уровень абстракции, потому что он вам не особо нужен и это нормально, но мы должны помнить, что класс должен делать/уметь/знать лишь то что ему нужно. Плюс хочу сказать что есть и более высокие уровни абстракции в построении тестов, но они могут быть вам не нужны. @evgmoskalenko, вот у вас в строке googleHomePage().openPage().searchFor(“qa automation framework”); например, новый объект new googleHomePage() указывается без ключевого слова new. Я указываю у себя создание объекта явно с использованием new. Конструктор LoginPage получает копию класса LoginData и использует ее в методе логина.