Одной из первых проблем, с которыми я столкнулся, когда я начал работать в ASOS, было использование фреймворка Cypress.io для написания самых первых интерфейсных автоматических тестов (FE) для одного из наших решений. По большей части у меня был опыт работы с Selenium Webdriver, который представлял собой уже устоявшуюся и хорошо известную платформу автоматизации в техническом сообществе.
Как известно большинству QA, одна из проблем FE-тестирования - убедиться, что тесты являются достаточно стабильными и надежными, чтобы справиться с динамической природой веб-страниц. Это была трудная задача даже с некоторыми из самых мощных фреймворков, так почему же с Cypress все должно быть иначе?
Что ж ... мы собираемся выяснить это, так как я хотел бы познакомить вас с некоторыми основами Cypress.
К счастью, начать с Cypress относительно легко. Онлайн-документация очень подробная, и я настоятельно рекомендую всем, кто плохо знаком с Cypress, потратить некоторое время на ее изучение, прежде чем писать свой первый тест.
Структура проекта Cypress.io
Сначала нам нужно было создать проект Cypress, который обычно выглядит примерно так 👇
Структура проекта в Cypress довольно проста. Все тесты должны находиться в папке интеграции, иначе Cypress Runner не сможет их обнаружить. Вы можете запускать тесты либо из Cypress runner, либо из командной строки.
Вы также найдете два очень важных файла конфигурации - package.json и cypress.json. Package.json отслеживает любые новые плагины, добавленные в проект, в то время как cypress.json позволяет вам добавлять значения конфигурации и изменять поведение Cypress по умолчанию.
Еще две папки, о которых стоит упомянуть, - это папка fixtures и папка support. Папка фикстур обычно содержит фиксированные данные (обычно в формате JSON), загруженные из файла, а папка поддержки содержит файл по умолчанию commands.js, который группирует вместе повторно используемые функции или методы. В одном проекте может быть несколько файлов commands.js.
Написание первого теста
В приведенном выше тестовом примере 👆 мы пытаемся нажать кнопку «одежда» на целевой странице ASOS, если она видна.
1. describe () - это поведенческая логика, полученная из интерфейса Mocha BDD и объясняющая, какая функция находится в стадии тестирования.
2. before () - это ловушка, содержащая логику, которую мы хотим запустить перед фактическим тестом.
3. cy.visit () - это команда cypress, которая переходит к определенному URL-адресу в Интернете.
4. it () - это функция Mocha BDD, которая предоставляет подробную информацию о том, что делает тест.
5. cy.get (‘data-cy = clothing_button’) определяет местонахождение веб-элементов на странице и является основным строительным блоком любого теста Cypress. Дальнейшие действия можно привязать к этой команде.
6. .should () - это утверждение BDD, которое проверяет, видна кнопка или нет.
7. .click () нажимает на веб-элемент, расположенный с помощью cy.get ().
Что нужно учитывать при написании тестов
Мы действительно любим следовать передовым практикам, и вот некоторые из вещей, на которые мы советуем обратить внимание:
- Тесты должны быть краткими и тестировать по одному.
- Разделите все тесты, которые тестируют разные функции, на отдельные классы. Это кажется очевидным, но это может сбить с толку других людей, пытающихся понять ваш код!
- При нахождении веб-элементов избегайте жесткого кодирования каких-либо значений.
- Напишите тесты, которые выполняются независимо друг от друга
- Переместите код настройки в хуки before () или beforeEach ()
- Переместите код разрыва в хуки after () и afterEach (), желательно очистить перед началом тестов. не после
Крутые вещи, на которые способен Cypress
Существует множество вариантов поведения FE, которые можно автоматизировать с помощью Cypress, например, навигация по веб-страницам, перетаскивание, заглушка запросов и ответов, взаимодействие с формами и вход в систему (SSO, JWT и т. Д.) И т. Д. Фактически, Cypress предоставляет так называемые рецепты, которые помогут вам начать работу с любой из этих функций.
Мы хорошо использовали большинство возможностей, упомянутых выше, в наших тестах, и на сегодняшний день наиболее сложными функциями были вход с помощью SSO и перетаскивание. Мы добились успеха с функциональностью входа в систему, однако у нас были некоторые проблемы с реализацией перетаскивания в основном из-за того, что сторонняя библиотека, используемая во время разработки, оказалась несовместимой с некоторыми командами cypress. Мы попробовали несколько подходов, предложенных онлайн, в том числе подход к тестированию, рекомендованный авторами сторонней библиотеки, и готовый к установке плагин drag and drop. Мы также обратились к сообществу кипарисовиков, но пока ответ остается загадкой.
В дальнейшем мы будем экспериментировать с данными динамического тестирования, поскольку мы хотели бы проводить наши тесты на разных доменах (и языках) веб-сайта ASOS. Я уверен, что мы узнаем больше интересного о Cypress, так что следите за обновлениями ...
Предостережения
Одним из ограничений, с которыми мы столкнулись при написании тестов, была поддержка кроссбраузерности, поскольку кажется, что Cypress пока предлагает поддержку только для Chrome. Это помогло бы покрыть больше земли. Однако выкатка этой возможности будет лишь вопросом времени.
Что мы сделали о Cypress.io
Cypress был очень ценен для моей команды с точки зрения охвата, скорости и надежности.
Сначала мы начали писать несколько тестов, чтобы добавить покрытие для функциональности, которую мы разрабатывали в то время, но, осознав, насколько легко было писать и поддерживать эти тесты, мы добавили еще 185 тестов, чтобы охватить критические сквозные (E2E) пути в нашем основном решении.
Недавно мы также создали конвейер непрерывной интеграции (CI) в Azure DevOps, который работает каждую ночь. В настоящее время для запуска полного набора тестов требуется около 19 минут, тогда как раньше для тестирования вручную требовался целый день. А теперь представьте, что вы повторяете эти тесты для проверки языковой локализации - обычно это занимает около недели!
Мы также отметили очень хорошие показатели успешности и согласованность тестовых прогонов.
Что я могу сказать? Cypress упростил нашу работу!
Шеррилен Гаучи (Sherrylene Gauci) - инженер по обеспечению качества в ASOS, работающая в отделе обслуживания клиентов. Вы можете застать ее каждый день в местном спортзале, тренируясь, чтобы стать следующей Тиа-Клер Туми. Также большой поклонник кофе.
