что такое page object model
Page Object — путь к совершенным автотестам
Всем, доброго времени суток!
Этот топик о том как мы тестируем веб-интерфейс нашего продукта Plus1 WapStart. Мы используем Page Object, т.к. этот паттерн имеет много общего с реальными задачами и позволяет писать автотесты простыми для чтения и понимания.
Что такое Page Object
Установка Ruby и gems
Для запуска примеров понадобиться последняя версия Ruby и gems:
Hello, Page Object!
Создаем RegistrationPage для страницы регистрации — для этого включаем модуль PageObject, указываем адрес страницы и описываем элементы:
На странице описаны шесть методов, каждый из которых дополнительно сгенерирует еще несколько, об этом далее… Добавляем данные по умолчанию:
Создаем метод для заполнения только обязательных полей:
Все базовые page objects определены, используем их в автотесте. Выберем драйвер selenium-webdriver, передав его в конструктор PageObject:
Аргумент true открывает page_url, если мы попадаем на эту страницу кликом по ссылке, то его можно не передавать. Запустим пример:
Таким образом в автотестах уходим от использования find_element и локаторов, код легко читаемый и повторно используемый.
Динамическая генерация методов доступа к элементам страницы
Accessors — методы класса, добавленные на страницу, подключением модуля PageObject. Методы генерируют еще один набор методов, которые обеспечивают доступ к элементам веб-страницы: 
Пример полностью описанной страницы регистрации:
Пример автотеста для проверки валидности партнерского кода:
Сайт тестировщика
Модель Page Object — на данный момент очень популярный фреймворк для автоматизации тестирования, многие компании работают с ним из-за его простоты обслуживания тестов и снижения дублирования кода.
Главное преимущество модели заключается в том, что в случае изменения структуры любой страницы, нам не нужно будет заново писать тесты, достаточно будет изменить код для объектов страниц (только в одном месте). Многие другие утилиты, основанные на Selenium, также следуют модели page object.
public class SignInPage <
private WebDriver driver;
private By headerPageText = By.cssSelector(|.hidden-small»);
private By createAccountLink = By.id(«link-signup»);
private By emailTextBox = By.id(«Email»);
private By passwordTextBox = By.id(«Passwd»);
private By loginBtn = By.id(«signIn»);
private By errorMsgTxt = By.id(«errormsg_0_Passwd»);
В коде выше сначала мы определили локаторы в классе SignInPage. Этим мы добились более высокой читабельности тестовых скриптов, мы можем легко добавить другие локаторы или изменить уже заданные — для этого потребуется внести изменения только в одном месте.
Модель Page Object подразумевает написание всех функциональных компонентов страницы, которые мы хотим проверять в наших тестовых скриптах, в отдельном классе. К примеру, мы можем создать отдельные классы для Главной страницы, страницы Авторизации и Регистрации.
Таким образом мы будем иметь классы HomePage.class, LoginPage.class, CreateAccountPage.class. В каждом классе мы определим также методы, которые относятся к странице этого класса.
К примеру, у нас есть стартовая страница google. У нее есть множество функций — таких как поиск, авторизация, Google+. При выполнении этих функций происходит переход на соответствующую другую страницу. Вся функциональность, которую мы хотим автоматизировать, должна находиться в методах и компонентов соответствующей страницы.
Поскольку при нажатии на определенные ссылки со стартовой страницы google мы переходим на другие страницы, нам нужно при таких переходах возвращать объекты этих страниц. Либо возвращать объект текущей страницы если действие не приводит к переходу на другую страницу, описанную в другом объекте страницы.
Модель Page Object предоставляет следующие преимущества:
Также эта модель позволяет при изменениях в дизайне страницы — менять соответствующий код только в одном месте. Полезная информация по данному фреймворку может быть найдена на множестве блогов, так как этот паттерн дизайна тестов становится очень распространенным. Приведем простой пример применения page object.
Пример описания функционала авторизации
* Tests login functionality
public void loginTestVase() <
WebDriverWait wait = new WebDriverWait(driver, 10);
String Expected = driver.findElement(By.id(«message»)).getText();
Если Вы посмотрите на тест описанный выше, то увидите что в нем нет разделения между кодом теста и кодом локаторов. Если в будущем структура страницы изменится, ее придется менять во множестве мест. Также будет трудно узнать где применяются эти локаторы, так как они могут находится в различных тестах.
Попробуем теперь переделать этот пример с помощью модели page object
* Tests login functionality
public void loginTestCase() <
//To go to home page
//To click on SignIn link
//To verify if user is navigated to sign-in page
//Login to the account
//To verify if user is navigated to user home page after successfull login
Несколько советов по созданию page object классов здорового человека
И снова здравствуйте. В преддверии старта курса «Java QA Engineer» подготовили перевод еще одной полезной статьи.
Это начало нового года, и многие люди во всем мире принимают решение уделять больше внимания своему здоровью. Это прекрасно! На самом деле, ваши тесты для фронтенда также нуждаются в таком решении.
Самым популярным паттерном проектирования, используемым в кодовых базах тестирования веб-UI, является паттерн Page Object Model (POM). Этот паттерн предполагает моделирование класса для представления одной страницы тестируемой системы. На основе этой модели, класс будет содержать свойства, которые представляют элементы страницы пользовательского интерфейса и методы, которые взаимодействуют с этими элементами.
Взяв за пример эту страницу входа в наше приложение, давайте обсудим советы по созданию класса с использованием POM.
Класс
Мы создаем единственный класс в нашей среде автоматизации для представления этой страницы. Рекомендуется убедиться, что имя класса соответствует странице в приложении, чтобы другие разработчики могли быстро найти класс, связанный с данной страницей пользовательского интерфейса.
Итак, в этом примере мы создадим класс с именем LoginPage.
Свойства
LoginPage должен содержать свойства для каждого из элементов на странице, которые будут использоваться в ваших тестах. Значения этих свойств являются указателями на элементы на реальной странице. Определяя эти локаторы в одном месте, вам не нужно будет хардкодить их в каждом месте, где вы их используете — таким образом, устраняя дублирование.
Методы
В дополнение к свойствам, класс должен также содержать методы, позволяющие тесту взаимодействовать с приложением, такие как заполнение полей ввода и нажатие кнопок. Вот несколько советов по разработке этих методов для оптимального использования в ваших тестах.
Добавьте геттеры и сеттеры
Целью POM классов является установка (set) и получение (get) состояния вашего приложения.Так что вам понадобятся соответствующие методы для этого.
Например, нам обязательно нужно установить поля username и password, поэтому необходимо добавить для них сеттеры.
Добавляйте только то, что нужно в настоящее время
Обратите внимание, мы не добавляли геттеры и сеттеры для каждого поля, потому что они не нужны нам в наших тестах. Добавляйте только то, что нужно в данный момент. Вы всегда можете добавить больше, если это потребуется для нового теста. Это избавит вас от необходимости поддерживать неиспользуемый код.
Переходы должны возвращать новые объекты
Вам также понадобятся методы для нажатия кнопок и ссылок. Однако, когда ваш клик приводит к смене страницы, ваш метод должен возвращать дескриптор класса, представляющего страницу пользовательского интерфейса, на которую вы перешли.
Например, если нажатие кнопки входа ведет к главной странице вашего приложения, тогда ваш метод должен вернуть дескриптор класса, представляющего эту главной страницу.
Благодаря поддержке данной рекомендации, все вызывающие тесты будут знать, что при вызове этого метода произойдет переход, и у теста есть дескриптор необходимого объекта для продолжения взаимодействия с приложением.
Не бойтесь создавать методы для удобства
Прямо сейчас для входа в приложение потребуется вызвать как минимум три метода (setUsername, setPassword и clickSignInButton). Поскольку они обычно используются вместе, имеет смысл предоставить в вашем классе удобный метод входа, чтобы ваши тесты могли вызывать только один метод.
Обратите внимание, что мы не реализовали логику в этом методе, а вместо этого просто вызвали отдельные методы. Важно, чтобы эти методы были доступны по отдельности, чтобы их можно было использовать в негативном тестировании (например, установить имя пользователя, но не пароль).
Учитывайте состояния
Для чекбокс-элементов (или других переключателей) простое нажатие на них может не соответствовать желаемому замыслу теста. Например, что если ваш тест хочет, чтобы чекбокс был установлен, но он уже установлен? Вызов метода клика в таком случае даст вам противоположный результат. Вместо этого сделайте свой метод более сложным, внедрив логику, которая будет ставить флажок только в том случае, если именно такой результат необходим пользователю. Чтобы сделать это, вместо слепого клика, примите аргумент, который указывает намерение (т. е. нам нужно, чтобы он был выбран или нет) и действовал соответственно.
Сохраняйте нейтральность POM классов
Ваш POM класс должен быть нейтральным объектом, который взаимодействует и собирает информацию о вашем приложении. Постарайтесь, чтобы ваши методы были нейтральными и убедитесь, что они достаточно универсальны, чтобы их можно было использовать в любом тесте, который хочет взаимодействовать со страницей. Это означает, что в эти методы не должны входить утверждения.
Например, что если наш метод, который получает сообщение об ошибке, также не проходит тест, если сообщение является видимым?
Я не могу повторно использовать этот метод для тестов, в которых я хочу убедиться, что отображается сообщение об ошибке, если имя пользователя или пароль неверны или не указаны. Это связано с тем, что POM класс взял на себя задачу определить, что отображение сообщения об ошибке является ошибкой; в то время как в этих случаях это не так. Вместо этого просто верните состояние и позвольте тесту определить, что оно означает.
Здоровый код предшествует здоровым тестам
Эти советы должны помочь вам разработать хорошие работоспособные классы, реализующие паттерн проектирования Page Object Model. Использование этого паттерна способствует разделению полномочий (например, тесты и управлением состоянием), уменьшает дублирование кода и предоставляет повторно используемые методы. Удачного тестирования!
Приглашаем всех на бесплатный вебинар, в рамках которого вы узнаете все подробности о курсе. А также мы займемся практикой и соберем из подручных средств заглушку для третьей системы и поговорим, как ее адаптировать для целей тестирования.
Selenium и Page Object паттерн
Разделение логики и реализации
Существует большая разница между логикой тестирования (что проверить) и его реализацией (как проверить). Пример тестового сценария: «Пользователь вводит неверный логин или пароль, нажимает кнопку входа, получает сообщение об ошибке». Этот сценарий описывает логику теста, в то время как реализация содержит в себе такие действия как поиск полей ввода на странице, их заполнение, проверку полученной ошибки и т.д. И если, например, измениться способ вывода сообщения об ошибке, то это никак не повлияет на сценарий теста, все также нужно будет ввести неверные данные, нажать кнопку входа и проверить ошибку. Но это напрямую затронет реализацию теста — необходимо будет изменить метод получающий и обрабатывающий сообщение об ошибке. При разделении логики теста от его реализации автотесты становятся более гибкими и их, как правило, легче поддерживать.
Page Object в Selenium
Паттерн Page Object в Selenium реализован с помощью библиотеки PageFactory и класса страницы. Page Object представляет собой отдельный класс, содержащий локаторы элементов, методы для работы с ними и конструктор принимающий в качестве параметра объект WebDriver. Методы класса Page Object могут возвращать объекты других Page Object классов. С помощью этого можно воссоздать копию переходов и поведения веб-приложения. Например, метод успешной регистрации в классе RegistrationPage должен возвращать экземпляр HomePage, потому что после регистрации на сайте пользователя перенаправляет на домашнюю страницу. Одним из следствий такого подхода является то, что необходимо моделировать как успешные, так и неуспешные методы. Или, например, в случае если нажатие на элемент может открывать различные страницы в зависимости от условий, то также необходимо создавать разные методы для каждого необходимого случая:
Каждый раз при обращении к элементу драйвер будет снова и снова осуществлять его поиск на странице. Для сложных AJAX-приложений это как раз то, что нужно. Но для ускорения выполнения существует возможность кешировать найденные элементы. Тогда поиск будет осуществляться только один раз при первом обращении к элементу.
Но делайте это только если вы уверены, что:
Пример класса Page Object:
Вызов методов страницы регистрации в тесте:
Реализация паттерна Page Object на Python + pytest
Когда я начинал изучать автоматизацию тестирования, не мог понять — “что такое Page Object и как его реализовать на Python + pytest?”. Штудируя интернет, нашел реализацию на других языках и фреймворках: обучающие статьи, которые были непонятны для меня. Поэтому решил написать этот разбор. Идея — показать реализацию на Python + pytest и объяснить ее доступным языком.
Что такое Page Object
Это популярный паттерн, который является де-факто стандартом в автоматизации тестирования веб-продуктов. Основная идея состоит в том, чтобы разделить логику тестов от реализации.
Каждую веб-страницу проекта можно описать в виде объекта класса. Взаимодействие пользователя описываются в методах класса, а в тестах остается только бизнес-логика. Данный подход помогает избежать проблем с тестами при изменении верстки веб-приложения. Вам необходимо поправить только класс, описывающий страницу.
Page Object определяет в себе части:
Схема паттерна Page Object.
Чтобы наглядно объяснить тему, реализуем автоматизированный тест.
Теоретическая часть реализации
Ожидаемый результат:
Пользователь перенаправлен на выдачу поиска. Выдача поиска имеет подпункты (видео, картинки и тд.).
Проверка: на странице поиска присутствует бар навигации и элементы “картинки” и “видео”.
Практическая часть реализации
Для понимания статьи необходимо знать базовые конструкции Python, ООП, понимать принципы и функции Selenium.
Будем использовать библиотеки: selenium и pytest. Установить их можно через пакетный менеджер pip.
Так же не забываем скачать драйвер для браузера. В статье используется chrome webdriver. Скачать его можно по ссылке. Для работы с ним положите файл в корневой каталог проекта.
Создаем фикстуру
Для начала необходимо реализовать инициализацию для WebDriver. Описывать её будем в фикстуре. Фикстуры в pytest — функции которые имеют свою периодичность выполнения.
Это альтернативная замена SetUp и TearDown методов в unittest. С помощью фикстуры, можно подготовить начальное состояние системы для проведения тестирования.
В pytest есть зарезервированное имя для файла с фикстурами — conftest.py.
Создаем файл conftest.py и реализуем функцию c именем — browser.
Помечаем ее декоратором @pytest.fixture и передаем параметр scope со значением session. Это означает что данная функция-фикстура будет исполнятся только 1 раз за тестовую сессию.
Далее мы описываем часть, которая будет выполнятся перед тестами. В ней происходит инициализация webdriver с указанием где располагается chromedriver. Далее используем конструкцию yield, которая разделяет функцию на часть — до тестов и после тестов.
В части “после тестов” мы вызываем функцию quit, которая завершает сессию и убивает экземпляр webdriver.
Base Page
Создаем файл BaseApp.py. В классе BasePage определяем базовые методы для работы с WebDriver.
В классе BasePage создаем конструктор, который принимает driver — экземпляр webdriver. Указываем base_url, который будет использоваться для открытия страницы.
Далее создаем методы find_element (ищет один элемент и возвращает его) и find_elements (ищет множество и возвращает в виде списка).
Это обертка над WebdriverWait, который отвечает за явные ожидания в Selenium.
В функции определяем время, которое по умолчанию равно 10-и секундам. Это время для поиска элемента. Метод go_to_site — вызывает функцию get из WebDriver. Метод позволяет перейти на указываемую страницу. Передаем в него base_url.
Page object
Наш класс для веб-страницы реализуется в файле YandexPages.py
Создаем класс YandexSeacrhLocators. Он будет только для хранения локаторов.
В классе описываем локаторы:
LOCATOR_YANDEX_SEARCH_FIELD — локатор поисковой строки
LOCATOR_YANDEX_SEARCH_BUTTON — локатор кнопки “Найти”
LOCATOR_YANDEX_NAVIGATION_BAR — локатор бара навигации (Картинки, Видео и т.д.)
Создаем класс SearchHelper, наследуемся от BasePage.
Реализуем вспомогательные методы для работы с поиском:
enter_word — ищет элемент строки поиска, кликает и вводит в поиск необходимое слово;
click_on_the_search_button — ищет элемент кнопки поиска и кликает на неё;
check_navigation_bar — ищет элементы навигации и получает атрибут text. Создает список и фильтрует по условию. Если длина строки больше нуля, то добавляет элемент к списку. Для примера, переопределим время по умолчанию установив его — 2 сек.
Tests
Создаем тестовую функцию test_yandex_seacrh, которая будет принимать фикстуру browser. Далее первой строчкой создаем объект страницы — yandex_main_page. Из объекта вызываем методы взаимодействия с элементами страницы. В функции описывается верхнеуровневая логика действий пользователя.
Перенесем все что реализовали на схему, аналогично схеме Page Object. Переименуем блоки под название файлов из статьи.
Как видите, нам удалось реализовать паттерн на практике.
Оставлю ссылку на готовый репозиторий. Спасибо за прочтение!