Использование POM в Cypress

Перевод статьи «Cypress for Dummies 3».

Начну с пояснения: данный шаблон проектирования уже давно является практически стандартным архитектурным шаблоном для множества работ по автоматизации. Мы все согласны с преимуществами, которые он дает. При этом мы иногда пренебрегаем некоторыми сложностями, которые он создает в долгосрочной перспективе.

Я думаю, мы ценим более современные подходы потому, что уже знакомы с объектной моделью Page Object Model (сокращенно POM) и реализовывали ее достаточно много раз, чтобы осознать ее недостатки. В этой статье я постараюсь объяснить важные части POM, которые мы реализуем.

По моему мнению, любой QA, начинающий свой путь в автоматизации, должен знать об этом паттерне. Так что я рекомендую вам изучить его и то, как он используется в различных фреймворках, таких как Selenium.

Еще одна оговорка: считается, что страничные объекты используются в объектно-ориентированном программировании, отсюда и пошло их название. В Cypress мы будем использовать функциональное программирование, поэтому применим некоторые концепции для POM, адаптированные для ФП.

Я не буду углубляться в детали, поскольку хочу, чтобы эта статья была короткой и практичной. Лучше рассмотрим преимущества POM.

Преимущества POM

1. Улучшение читаемости и сопровождения. POM отделяет структуру и макет страницы от тестовых сценариев, что делает код более читаемым и простым в сопровождении. Изменения в пользовательском интерфейсе можно вносить в одном месте, а не в каждом тесте, что также упрощает сопровождение.
2. Возможность повторного использования кода. Классы страниц могут быть переиспользованы в нескольких тестовых сценариях, что позволяет сократить дублирование кода. Это не только экономит время, но и снижает вероятность ошибок.
3. Уменьшение количества модификаций скриптов. Изменения пользовательского интерфейса требуют обновления только объектов страницы, а не тест-кейсов. По этой причине уменьшается необходимость модифицировать тестовые скрипты при изменении UI, что приводит к более стабильному набору тестов.
4. Модульность. Данная модель поощряет модульный подход к разработке тестовых сценариев. Создавая модульные тест-кейсы, тестировщики могут строить более масштабируемые и понятные тестовые сценарии.
5. Повышение качества совместной работы. POM приводит к созданию более организованного и понятного кода. Поэтому командам, особенно таким, в которых работает несколько инженеров по автоматизации, легче сотрудничать при разработке тестовых сценариев.
6. Упрощение поиска и устранения неисправностей. При четком разделении структуры страницы и тестов становится проще определить, где кроются проблемы — в логике тестового сценария или в реализации объекта страницы.
7. Интеграция с другими инструментами. POM хорошо работает со многими инструментами тестирования и фреймворками, что делает ее применение универсальным подходом, позволяющим интегрироваться в различные экосистемы тестирования.

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Реализация POM

Реализация POM проста. Но, как всегда, когда дело доходит до написания кода, нужно быть последовательным. Основная идея — в разделении автоматизации функций по разным слоям (отдельным каталогам), а также по разным файлам на основе страниц AUT. AUT расшифровывается как Application Under Testing — «тестируемое приложение».

Базовыми слоями являются:

• Объекты страницы. Они предназначены для группировки всех элементов страницы из нашего AUT.
• Определения шагов. Они предназначены для группировки всех функций для взаимодействия со страницей из нашего AUT.

К дополнительным слоям относятся:

• Фичи (если вы реализовали какую-либо форму gherkin).
• Утилиты (вы можете использовать эти файлы, если создаете сложную логику, которая может переиспользоваться).

Шаг 1. Создание файлов страниц

(В проекте объектно-ориентированного программирования это будут классы).

Начнем со страничных объектов, которые представляют собой файлы, определяющие сам шаблон POM. Их назначение — содержать элементы, с которыми вы будете взаимодействовать на каждой странице вашего приложения. Возвращаясь к примеру, для реализации нашего теста нам потребуется 2 страницы.

Я создам файлы home.page.js и login.page.js, но для начала нам нужно место для их хранения. В моем примере это каталог pageobjects.

Шаг 2. Определение элементов страницы

Теперь, когда у нас есть страницы, необходимо определить, с какими элементами на них мы будем взаимодействовать.

Мы создаем эти элементы как константы в соответствующем файле. Как вы понимаете, некоторые селекторы повторяются. Чтобы иметь возможность их переиспользовать и в случае изменения любого из них вносить обновления только в одном месте, мы можем создать константы для каждого элемента в соответствующем файле. Т.е., если изменится ID селектора кнопки входа в систему, то нам нужно будет изменить его только в объекте страницы, и тест продолжит работать должным образом.

Теперь я заменю селекторы их строками, и вы увидите, как код станет более читабельным.

Шаг 3. Реализация функций высшего порядка

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

Я просто буду использовать его для хранения некоторых полезных функций, которые помогут мне упростить взаимодействие со страницами. Например — для щелчков по элементам и ввода текста в поля.

В рамках реализации функций мы можем также реализовать базовое взаимодействие элементов на страницах.

Шаг 4. Реализация определений шагов

Допустим, у нас есть несколько шагов с более сложной логикой. Или мы обнаружили, что некоторые функции, которые нам нужно выполнить, в дальнейшем можно переиспользовать или перепрофилировать с другой логикой.

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

Заключение

Единственное, на что я бы рекомендовал обратить внимание, — это правильный нейминг. Когда имена функций и переменных представляют части приложения, это помогает легко определять места поломок и сокращать время, необходимое для отладки и исправления тестов.

Среди других практик — именование страниц и файлов шагов на основе того же имени, которое команда дала странице AUT. Например, login. У нас есть файл login.page.js и login.steps.js.

Еще одна вещь, которую вы можете рассмотреть, это перемещение ваших тестов в одну директорию, в которой вы можете лучше их организовать. Например, в  папку feature.