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

Если в определённый момент разработчики изменят id у логотипа, то все one hundred тестов будут заканчиваться неудачей и мне надо будет править все a hundred тестов. Мы создадим класс, описывающий главную страницу сайта, а также класс описывающий страницу результатов поиска и в них будут перечислены все элементы страниц, к которым мы потом будем обращаться из всех one hundred тестов. И когда разработчики изменят id у логотипа или ещё у какого-то из сотен элементов, то мы исправим его в одном месте, а сами тесты не будем трогать. Самое сомнительное использование наследования в страничных объектах — это просто собрать все возможные полезные вспомогательные классы в одном месте, для удобства автоматизатора.

Но ни разу не видели случая, когда ценность умного подхода компенсировала бы созданную им сложность. В автоматизации тестирования, как и в общей разработке программного обеспечения, избегайте излишне умных подходов. Реализация интерфейса объекта страницы для поддержки цепочки методов может быть выполнена даже в функциональных языках, таких как javascript. Независимо от того, как он реализован, это ценный инструмент для улучшения читаемости тестов при использовании Page Objects. Эта схема добавления прослойки между объектами страницы и тестами на самом деле довольно распространена. Автоматизаторы видят кучу повторяющихся шагов в куче тестов, создают «помощника», который собирает эти шаги в одном месте, и используют этого помощника.

Его имя, DuckDuckGoSearchPage, уникально и внятно определяет страницу. В нем есть атрибуты локаторов (SEARCH_INPUT), инициализатор (__init__) и методы взаимодействия (load и search). Действия над идентифицированными элементами выполняются с использованием методов public void. Это повторяется для обеих страниц тестируемого приложения. Каждый объект страницы будет содержать множество локаторов для соответствующих элементов на этой странице. Видя все локаторы на всех страницах, возникает соблазн собрать эти локаторы в некий централизованный класс Locators, и ссылается на него в каждом Page Object.

Однако большинство современных веб-приложений не строятся как набор уникальных страниц. Вместо этого страницы собираются из набора многократно используемых компонентов. Например, компонент заголовка может находиться в верхней части каждой страницы, а компонент корзины — в правой части большинства страниц, связанных с покупками. Я не буду сейчас рассказывать, что такое Page Object (паттерн/шаблон проектирования, который используется в автоматизированном тестировании) или Page Factory (класс из библиотеки Selenium), так как в интернете много информации о них. В данной статье я постараюсь на примерах показать, как с ними необходимо работать, чтобы вы взяли и начали сразу применять, то о чём мы сегодня будем говорить. В классе BasePage создаем конструктор, который принимает driver — экземпляр webdriver.

Из объекта вызываем методы взаимодействия с элементами страницы. В функции описывается верхнеуровневая логика действий пользователя. После этого лучшей стратегией для глубокого понимания страничных объектов является не чтение об объектах страниц, а чтение и понимание принципов проектирования программного обеспечения и паттернов проектирования. Автоматизация тестирования — это разработка программного обеспечения, и все знания, относящиеся к программному обеспечению, относятся и к автоматизации тестирования. Читайте о SOLID, читайте больше о DRY vs DAMP, изучайте все другие паттерны проектирования и как они используются, изучайте функциональное программирование и как эти концепции применяются по-разному, список тем практически бесконечен.

Автоматизация Тестирования По

Всё просто — есть элементы сайта, которые мной используются многократно в разных тестах. Если разработчик изменит элемент, а он используется мной в one hundred тестах, то мне придётся править a hundred мест в коде. При автоматизация ui тестов box использовании Page Object мне достаточно исправить код в одном месте. Это популярный паттерн, который является де-факто стандартом в автоматизации тестирования веб-продуктов. Основная идея состоит в том, чтобы разделить логику тестов от реализации.

Создаем файл conftest.py и реализуем функцию c именем — browser. В pytest есть зарезервированное имя для файла с фикстурами — conftest.py. Страница LoginPage состоит из двух полей ввода User и Password, кнопки Login. При отправке корректного логина и пароля открывается страница Home на которой есть имя пользователя и ссылка Logout. При отправке НЕкорректного логина и пароля открывается страница ErrorLogin, на которой есть сообщение об ошибке и ссылка Back To Login Page. Разработку программного обеспечения легко изучить, но трудно освоить, и это часть того, что делает ее такой увлекательной.

Как мы уже говорили, набрав в Google «Page Object», вы получите миллион просмотров. Однако каждый уважающий себя автоматизатор тестов должен хотя бы прочитать статью Мартина Фаулера на эту тему. Связанность — это принцип проектирования, который описывает степень зависимости или взаимосвязанности между частями системы. Если две части имеют значительную зависимость друг от друга, если изменения в одной части требуют значительных изменений в другой, мы говорим, что эти две части имеют высокую связанность. Именно здесь на помощь приходит модель актора или агрегатора. Эти названия взаимозаменяемы, и я видел, как этот паттерн называли по-разному, но независимо от названия все они служат одной цели.

В следующий раз мы научимся конфигурировать выбор браузера и ожидания вне кода автоматизации, используя config-файлы. То есть если уж вы объявляете поля для элементов, то пусть они будут приватными, а все операции с ними пусть осуществляются через публичные методы. Для этой страницы важным элементом будет заголовок страницы, подтверждающий, что авторизация была успешно завершена.

Классический Вариант Web Page Object

Акторы объединяют действия между объектами страницы, чтобы представить эти общие агрегированные действия на страницах в виде многократно используемых фрагментов. Они обеспечивают интерфейс более высокого уровня для тестов. Таким образом, каждому тесту не нужно заново реализовывать эту последовательность, он просто использует интерфейс, предоставляемый актором. Наш тест взаимодействует с двумя страницами – страницей поиска DuckDuckGo и страницей результатов. Создайте новую директорию pages/ в корневом каталоге проекта, и добавьте пустой файл __init__.py, чтобы сделать ее пакетом. В этом пакете вам нужно создать два файла – search.py и outcome.py.

Паттерн Page Objects

Паттерн Page Object, также известный как “модель Page Object” – это паттерн проектирования, который извлекает взаимодействия веб-страницы с целью улучшить их читабельность и повторное https://deveducation.com/ использование. Страницы представлены как классы с атрибутами локаторов и методами взаимодействия. Вместо сырых вызовов WebDriver тесты вызывают методы объекта страницы.

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

Как и во всем остальном, при попытке создать DRY или DAMP код все еще существует огромное количество гибкости и критического мышления — то, что является DRY для одного человека, может показаться быть «недостаточно DRY» для другого. Автоматизация тестирования — это не формула, и вам придется использовать свой мозг и свою интуицию. Да, в этом паттерне мы берем кучу шагов и объединяем их для повторного использования в тестах, но это скорее изменение уровня абстракции, который подходит для оптимальной читаемости тестов, чем удаление дублирования. DAMP улучшает читабельность, и мы использовали актор именно для улучшения читабельности. На практике такое использование наследования не добавляет значительной ценности, кроме доказательства того, что автоматизатору нравится использовать наследование. Того же результата можно было бы достичь, используя компоненты страницы и простую композицию, или просто допустив минимальное дублирование на страницах, специфичных для каждого языка.

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

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

Паттерн Page Objects

Строка ShopperActor.logonAndSelectItem(); говорит мне именно то, что мне нужно знать, чтобы понять, что делает тест. Этот принцип называется DAMP — Descriptive and Meaningful Phrases (понятные и осмысленные фразы). Он отдает приоритет многословию для удобочитаемости, а не дублированию, и должен стать вашим руководящим принципом в тестах. Такова цель каждого паттерна проектирования, о котором вы когда-либо читали. Прикладываю готовый проект с описанными выше примерами. Вообще, вариантов реализации PageObject-ов может много в зависимости от предпочтений того или иного разработчика.

Не является исключением и тестирование программного обеспечения. Сегодня мы с вами рассмотрим использование Page Object и Page Factory. В части “после тестов” мы вызываем функцию stop, которая завершает сессию и убивает экземпляр webdriver. Далее мы описываем часть, которая будет выполнятся перед тестами.

В реальности тут будет намного больше информации, но для наглядности нам и этого достаточно. Для начала необходимо реализовать инициализацию для WebDriver. Фикстуры в pytest — функции которые имеют свою периодичность выполнения. Это альтернативная замена SetUp и TearDown методов в unittest. С помощью фикстуры, можно подготовить начальное состояние системы для проведения тестирования.

Это понимание паттернов проектирования не диктует каждую деталь ваших страничных объектов. Вот почему автоматизация тестирования требует критического и творческого мышления, свойственного разработке программного обеспечения, и не является шаблонной. Если вы знакомы с любым видом фронтенд-веб-разработки, то, возможно, сталкивались с Document Object Model (DOM). DOM широко признан как тип API для документов HTML и XML, позволяющий получать доступ к логической структуре документа и манипулировать ей.

Например, объект BasePageObject будет либо объединять, либо компоновать хелперы для работы с базой данных, хелперы для работы с assertion-ами и все остальные хелперы. Таким образом, каждый объект страницы, производный от базового объекта страницы, сразу получает доступ ко всему и всем, что ему может понадобиться. Не имеет смысла дублировать знания о том, как найти элементы в компоненте заголовка, на все объекты страницы, включающие заголовок. Вместо этого создавайте Page Components (компоненты страницы), которые связаны с меньшими частями страниц (в нашем примере — с заголовком).