Как установить cypress на windows

Обновлено: 04.07.2024

Чтобы продолжить, вам понадобится рабочая установка Node.js в вашей системе. Кроме того, полезно иметь базовое понимание нового синтаксиса JavaScript.

Что такое Cypress? Что такое сквозное тестирование?

Важно ли сквозное тестирование? Да, это так. Но никто не любит тесты E2E. Они могут быть медленными, громоздкими и дорогими в написании.

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

Настройка проекта

Создадим новую папку cypress-tutorial, зайдем в нее и инициализируем новый проект JavaScript:

Внутри этой папки создадим два новых файла.

HTML-документ index.html:

Это HTML-форма с набором входных данных и текстовым полем textarea.

Затем создайте файл JavaScript form.js с минимальной логикой для обработки отправки формы:

Обратите внимание, что я не добавил стили для простоты примера. Теперь, мы готовы установить Cypress.

Установка Cypress

Чтобы установить Cypress, все еще находясь в папке проекта, запустите:

Дайте ему минуту (ему нужно скачать двоичный файл), а затем запустите:

Cypress запустится в первый раз, и в вашем проекте появится куча новых папок. Вы можете безопасно удалить папку с примерами (examples).

Закроем окно и перейдем к следующему разделу.

Запуск проекта

Для запуска проекта на локальном компьютере убедитесь, что у вас установлена новая версия Node.js, а затем запустите команду:

Теперь пора написать наш первый тест!

Написание первого теста

Создайте новый файл в cypress/integration/form.spec.js и напишите свой первый блок:

Как видите, он принимает два аргумента: строку для описания набора тестов и функцию обратного вызова для обертывания фактического теста.

Далее мы встретимся с другой функцией, называемой it, которая является фактическим тестовым блоком:

Если вы знаете Jest, вы можете вспомнить, что он использует it или test взаимозаменяемо. В случае с Cypress дело обстоит иначе. it единственный возможный блок.

А теперь время для дымового теста (smoke test)! В блоке it напишите:

Через минуту мы увидим Cypress в действии, но сначала немного настроек!

Настройка Cypress

Чтобы немного упростить работу, мы собираемся настроить Cypress. Для начала откройте package.json и создайте скрипт с именем e2e, указывающий на двоичный файл Cypress:

Команда open запускает визуальное отображение прохождения тестов (в браузере видимое для программиста). Есть еще команда run которая запускает прохождение тестов в консоле.

Затем откройте cypress.json и настройте базовый URL:

Теперь мы готовы запустить ваш первый тест!

Запускаем тест

Готовы? Когда сервер разработки все еще работает в терминале:

откройте другой терминал и запустите:

Вы должны увидеть, как Cypress откроет браузер и отобразить страницу. После запуска теста на странице будет что то типа такого:

Теперь давайте продолжим расширять наш тест, чтобы увидеть, может ли пользователь заполнить форму:

Вот еще одна команда Cypress: type, которая, что неудивительно, вводит в наш input элемент указанный текст. Также обратите внимание на селектор CSS для получения элемента ввода.

А пока давайте добавим еще одну команду: should. Эта команда создает утверждение и используется, например, для проверки того, обновляет ли input элемент свое состояние должным образом:

Обратите внимание на have.value. Если вы новичок в этой концепции, вы можете узнать больше об утверждениях здесь.

Проведя минимальный тест, продолжим в следующем разделе.

Больше тестов и Submit

Чтобы продолжить наш тест, мы можем проверить ввод электронной почты:

Также мы можем проверить текстовую область textarea:

Если вы оставили Cypress открытым, тест должен отслеживать ваши изменения и запускаться автоматически:

Как мило! В качестве вишенки на торте давайте протестируем отправку формы с помощью submit:

Тест должен пройти без проблем. Вы можете заметить одну вещь: все используемые команды с самоописанием: type, submit. Это простой английский.

Теперь давайте немного пофантазируем в следующем разделе с тестированием запросов XHR.

Заглушка запросов XHR с помощью Cypress

Помимо всего прочего, Cypress также может перехватывать запросы AJAX и имитировать ответы. Этот подход известен как stubbing (заглушка).

Чтобы понять разницу между mocking и stubbing, прочтите этот пост.

Stubbing удобен при разработке, когда вам нужен возврат фальшивого ответа на ваши запросы AJAX.

Чтобы продемонстрировать эту возможность, давайте добавим в наш тест следующий фрагмент кода:

Здесь cy.server запускает «виртуальный» сервер, в то время как cy.route настраивает поддельную конечную точку API.

Теперь давайте добавим еще один тест для проверки: после того, как пользователь отправит форму, мы хотим проверить, отвечает ли поддельное API.

Использование stubbing полезно, потому что мы можем полностью обойти настоящее API в процессе разработки. Давайте расширим тест с помощью cy.contains:

Ожидается, что тест завершится неудачно, потому что нет логики для отправки формы в API. В следующем разделе мы поправим тест.

Отправка данных формы в API

~~На момент написания Cypress не мог перехватывать запросы Fetch.~~ Начиная с версии 4.9.0 Cypress имеет экспериментальную поддержку Fetch stubbing. Чтобы включить его, настройте experimentalFetchPolyfill в cypress.json:

В этом фрагменте я использую событие formdata, вызываемое, когда мы вызываем new FormData.

В прослушивателе событий мы создаем объект с fromEntries (ECMAScript 2019). Далее мы отправляем данные в API.

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

Пришло время посмотреть на прохождение теста!

Заглушка запросов XHR с помощью Cypress: успешный тест

Подведем итоги полного теста в cypress/integration/form.spec.js:

Вот полный код для form.js:

Следует иметь в виду, что настоящее API вряд ли вернет ту же форму, что и наша фальшивая заглушка. При разработке реального приложения вам действительно необходимо адаптировать свои тесты к реальной системе.

На данный момент у нас все в порядке, и если вы оставили Cypress открытым, вы уже должны увидеть успешное прохождение теста:

Вы можете увидеть раздел маршрутов вверху слева и заглушку XHR в тестовых выходных данных, это означает, что Cypress перехватил запрос POST.

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

Данной заглушкой можно закончить урок. Прекрасная работа!

Выводы

Я надеюсь, что вы узнали что-то новое из этого урока, и вы примените эти концепции в своем следующем проекте! Тестирование важно!

Сквозное тестирование не должно быть трудным: Cypress делает его приятным и приятным. Команда Cypress действительно справилась с этим.

Кроме того, есть очень подробная документация: Cypress Docs наполненная передовыми практиками и примерами.

Разработчики обычно озабочены качеством своего кода. Существуют различные виды тестов, которые помогают нам избежать нарушения кода при добавлении новой функции в проект. Но что мы можем сделать, чтобы компоненты не менялись со временем?

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

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

К концу поста у нас будут PR с тестами Cypress:

Прежде чем мы начнем

Я создал образец веб-сайта, имитирующий библиотеку компонентов. Это очень простой веб-сайт, созданный с помощью TailwindCSS и размещенный на Vercel. Он документирует 2 компонента: значок и кнопку.

Добавление Cypress Image Snapshot и Cypress

Начните с клонирования репозитория примеров. Затем создайте новую ветку и установите Cypress Image Snapshot, пакет, отвечающий за захват / сравнение снимков экрана.

После добавления пакетов необходимо выполнить несколько дополнительных шагов, чтобы добавить Cypress Image Snapshot в Cypress.

Создайте файл cypress/plugins/index.js со следующим содержанием:

Затем создайте файл cypress/support/index.js , содержащий:

Создание теста скриншота

Пришло время создать тестовый скриншот. Вот план:

Cypress посетит каждую страницу (значок и кнопку) проекта.
Cypress сделает снимок экрана каждого примера на странице. На странице значка есть 2 примера (по умолчанию и таблетка), а на странице кнопки есть 3 примера (по умолчанию, таблетка и схема). Все эти примеры находятся внутри элемента <div> с расширением cypress-wrapper . Этот класс был добавлен с единственной целью - определить, что нужно протестировать.

Первым шагом является создание файла конфигурации Cypress ( cypress.json ):

Это веб-сайт baseUrl , работающий локально. Как я уже упоминал ранее, npm run serve будет обслуживать содержимое папки public . Второй вариант, video отключает запись видео Cypress, которую мы не будем использовать в этом проекте.

Пришло время создать тест. В cypress/integration/screenshot.spec.js , добавьте:

В приведенном выше коде я динамически создаю тесты на основе массива routes . Тест создаст одно изображение для каждого элемента .cypress-wrapper страницы.

Наконец, внутри package.json давайте создадим команду для запуска тестов:

Отсюда есть 2 варианта: запустить Cypress в автономном режиме npm run cypress run или использовать Cypress Test Runner с npm run cypress open .

Headless вариант

При использовании npm run cypress run вывод должен быть похож на следующее изображение:

Тесты пройдут, и в папке /snapshots/screenshot.spec.js будут созданы 5 изображений.

Вариант Test Runner

Используя npm run cypress open , откроется Cypress Test Runner, и вы сможете шаг за шагом следить за тестами.

Наша первая веха пройдена, поэтому давайте объединим эту ветку в master. Если вы хотите увидеть проделанную работу, перейдите в мой Pull Request.

Использование Cypress внутри Docker

Если вы запустите вышеуказанный тест попеременно между Headless и Test Runner, вы можете заметить, что снимок экрана будет отличаться.

Используя Test Runner с компьютером с дисплеем Retina, вы можете получить изображения (2x), в то время как режим Headless не дает вам скриншотов высокого качества.

Также важно сказать, что снимки экрана могут отличаться в зависимости от вашей операционной системы.

Например, в Linux и Windows есть приложения с видимыми полосами прокрутки, а в macOS полоса прокрутки скрыта.

Если содержимое, захваченное на снимке экрана, не подходит для компонента, у вас может быть полоса прокрутки, а может и нет. Если ваш проект использует шрифты ОС по умолчанию, снимки экрана также будут отличаться в зависимости от среды.

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

Начнем с создания новой ветки:

Cypress предлагает различные образы Docker - вы можете проверить подробности в их документации и их блоге.

В этом примере я буду использовать изображение cypress/included , которое включает Electron и готово к использованию.

Нам нужно внести два изменения: изменить baseUrl в файле сypress.json :

и команду test в файле package.json :

Запуск npm run test принесет нам проблему:

Изображения немного отличаются, но почему? Посмотрим, что внутри папки __diff_output__ :

Как я уже упоминал ранее, несоответствия в типографике! Компонент Button использует шрифт ОС по умолчанию. Поскольку Docker работает внутри Linux, визуализированный шрифт не будет таким, который я установил в macOS.

Поскольку сейчас мы перешли на Docker, эти скриншоты устарели. Время обновить снимки:

Обратите внимание, что я добавляю к команде test префикс переменной среды CYPRESS_updateSnapshots .

Второй этап пройден. Если вам нужна помощь, ознакомьтесь с моим pull request.

Давайте объединим эту ветку и двинемся дальше.

Добавление CI

Наш следующий шаг - добавление тестов в CI. На рынке есть различные решения CI, но для этого урока я буду использовать Semaphore. Я не связан с ними и использую их продукт на работе, так что это был для меня естественный выбор.

Конфигурация проста и может быть адаптирована к другим решениям, таким как CircleCI или Github Actions.

Прежде чем мы создадим наш файл конфигурации Semaphore, давайте подготовим наш проект к запуску в CI.

Первый шаг - установка start-server-and-test. Как указано в названии пакета, он запустит сервер, дождется URL-адреса, а затем выполнит тестовую команду:

Во-вторых, отредактируйте файл package.json :

В скрипт test мы добавляем переменную окружения CYPRESS_baseUrl . Это позволит нам динамически изменять базовый URL, используемый Cypress. Также мы добавляем скрипт test:ci , который будет запускать только что установленный пакет.

Мы готовы к Semaphore. Создайте файл .semaphore/semaphore.yml со следующим содержимым:

Подробная разбивка конфигурации:

Еще одна веха пройдена, пора объединить нашу ветку! Вы можете проверить Pull request, который содержит все файлы из этого раздела, и проверить сборку внутри Semaphore.

Запись тестов в cypress.io

Чтение вывода тестов в CI не очень дружелюбно. На этом этапе мы интегрируем наш проект с cypress.io.

Следующие шаги основаны на документации Cypress.

Начнем с получения идентификатора проекта и ключа записи. В терминале создайте новую ветку и запустите:

Ранее я упоминал, что мы будем использовать Cypress внутри Docker. Но здесь мы открываем Cypress локально, поскольку это единственный способ интеграции с панелью управления веб-сайта.

Внутри Cypress перейдите на вкладку «Runs», нажмите «Set up project to record» и выберите имя и доступность. Мы получим projectId автоматически добавляемый в файл cypress.json и закрытый ключ записи. Вот видео с шагами:

В Semaphore я добавил ключ записи как переменную среды с именем CYPRESS_recordKey . Теперь давайте обновим наш тестовый сценарий, чтобы использовать переменную:

Это почти все, что нужно сделать. В Pull request мы видим интеграцию cypress.io в комментариях. Есть даже глубокая ссылка, которая ведет нас на их панель управления и показывает все скриншоты. Посмотрите видео ниже:

Пора объединить нашу работу, и это конец нашей интеграции.

Тестирование в реальной жизни

Представьте, что мы работаем над изменением, которое влияет на заполнение кнопок: пора проверить, улавливает ли Cypress разницу.

В примере веб-сайта давайте удвоим горизонтальный отступ с 16 до 32 пикселей. Это изменение довольно просто, поскольку мы используем Tailwind CSS: px-4 заменяется на px-8 . Вот этот Pull request.

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

Файл сравнения показывает исходный снимок экрана слева, текущий результат справа, и они объединены в середине. У нас также есть возможность загрузить изображение, чтобы лучше понять проблему:

Если это не проблема, обновите скриншоты:

Конец

На сегодня все. Я надеюсь, что вы узнали, как Cypress может быть полезен, чтобы гарантировать, что никто не добавит неожиданные изменения в проект.

Что пишут в блогах

Онлайн-тренинги

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Автор: Тоби Стид (Toby Steed)
Оригинал статьи
Перевод: Ольга Алифанова

Я вначале отбросил Cypress, потому что предпочитаю работать с библиотеками, а не фреймворками. Мне нравится, когда я свободен в построении своего собственного фреймворка вокруг выбранных мною для решения проблемы библиотек. Cypress – готовый фреймворк "из коробки", и со временем я понял, как он хорош. Он очень мощен прямо с момента установки, и в нем можно быстро и легко написать хорошие, устойчивые тесты – кривая обучения у него довольно пологая.

Если вы ранее не пользовались Cypress, то эта серия статей поможет вам легко установить Cypress и начать писать тесты. Мы даже разовьем этот опыт, воспользуясь Page Object, создадим свои собственные вспомогательные классы, и напишем кастомные команды для расширения возможностей фреймворка. В первой части цикла мы установим новый проект Cypress, настроим его и напишем наш первый тест.

Прежде чем начать, вам нужно установить Visual Studio Code и Node.Js (на момент выхода этой статьи актуальная версия – 1.18.0, но если что-то изменилось, просто воспользуйтесь самой последней версией).

Допустим, что все это уже установлено. Поехали!

Создайте новую директорию для проекта, и, открыв VSCode, используйте эту команду в терминале (Ctrl+Shift+’), чтобы изменить активную директорию на проектную:

Это необязательный шаг, но всегда неплохо инициализировать проектную директорию с базовыми необходимыми файлами, работая с npm-пакетами:

npm install cypress –dev

npx cypress open

npx – не опечатка, эта команда объединена с npm и позволяет куда быстрее запускать Cypress. Введя ее, вы получите строку текста в терминале, сообщающую, что вы запускаете Cypress для этого проекта впервые. Затем она пропадет, настроит много чего еще, и когда все это закончится, Cypress стартует! У нас появится новый модный дашборд, но что еще важнее – в проекте появится новая папка и файлы, которые можно начинать использовать. К дашборду мы еще вернемся – давайте посмотрим в код и разберемся, что же у нас теперь есть.
Сначала вы увидите папку Cypress, с которой мы будем работать в ряде следующих статей. Внутри она разделена так:

cypress/fixtures

cypress/integration

cypress/plugins

cypress/support

И в корневой папке будет файл конфигурации:

foldername/cypress.json

В папке Integration будут жить ваши тесты. Внутри нее можно создавать новые папки, чтобы структурировать тесты так, как вам надо, но все тесты всегда должны находиться только внутри этой папки. Cypress автоматически подхватит все .js-файлы из этой папки и добавит их на дашборд. Если вы запускаетесь через Cypress CLI, то тесты автоматически подхватятся, если вы прогоняете все тесты и не пользуетесь кастомными командами.
Папка Fixtures будет содержать все нужные вам данные в JSON-формате. Это могут быть ответы на запрос или другие специальные данные, но они должны храниться в формате JSON.
В папке Plugins по умолчанию находится единственный файл – index.js, и для 90% тест-задач его вам хватит за глаза. В этот индекс-файл будут добавляться все плагины, которые нужны вам на глобальном уровне.
И, наконец, папка Support. Она похожа на папку Plugins, в ней тоже лежит индекс-файл, нужный для объявления глобальных модулей, которые вы не хотите импортировать для каждого файла. Также там находится файл команд, в котором можно создавать кастомные команды для Cypress. Они пригодятся для расширения Cypress или описания нужных вам методов.
Мы подробнее разберемся с этим в ходе цикла статей, но пока не волнуйтесь о них. Сейчас вам нужна только папка Integration – там мы будем создавать первый тест! Добавьте новый файл в эту папку, назовите его как хотите, но для целей этой статьи назовем его FirstTest.spec.js. Важно, чтобы в имени файла было слово spec, иначе Cypress не поймет, что это валидный тестовый файл, и не увидит в нем тесты.
Теперь, когда у нас есть тест-файл, напишем базовый тест. Как выглядит Cypress-тест, и что все это значит?

Уверен, вы согласитесь, что это очень сложный тест. Но все равно поздравляю – вы написали ваш первый тест в Cypress! Что же он делает?

Describe – это имя вашей спеки или тест-набора. Если улучшить это название, можно сделать его describe(‘Google Home Page’).

"It" – это имя теста внутри тест-набора, и тут снова используется обычный язык для описания теста. Мы в общем-то неплохо справились с названием в примере выше.

Внутри самого теста можно заметить, что шаги начинаются с ключевого слова "cy". Как и в Selenium, вы будете часто применять ключевое слово "driver" – в Cypress это "cy".

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

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

Если нажать на ваш тест-файл, откроется новое окно – это Cypress-браузер, запускающий ваш тест. Он закончится, не успев начаться, и вы увидите приятный зеленый цвет, потому что тест сработал верно. Поздравляю!

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

Разработчиков, как правило, заботит качество кода. Есть различные виды тестов, которые помогают избежать ситуаций, когда код ломается после добавления в проект новой функции. Но как можно гарантировать, что компоненты с течением времени не изменятся внешне?

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

На создание этой стратегии тестирования меня мотивировала работа. В Thinkific есть внутренняя система проектирования, и мы добавили к ней Cypress, чтобы избежать сюрпризов при работе с файлами CSS/JS.

К концу этой статьи у нас будет репозиторий с тестами Cypress:

Для имитации библиотеки компонентов (Component Library) я создал сэмпл веб-сайта. Это очень простой сайт, сделанный с помощью TailwindCSS и размещенный в Vercel. Он документирует два компонента: значок и кнопку.

Начните с клонирования репозитория-образца. Затем создайте новую ветку и установите Cypress Image Snapshot, пакет, отвечающий за захват и сравнение скриншотов.

После добавления пакетов необходимо выполнить несколько дополнительных шагов, чтобы добавить в Cypress Cypress Image Snapshot.

Создайте файл cypress/plugins/index.js со следующим содержимым:

Далее создайте файл cypress/support/index.js , содержащий:

Пришло время создать тест для скриншотов. План таков:

Первый шаг — создание конфигурационного файла Cypress (cypress.json) :

BaseUrl здесь — веб-сайт, который запущен локально. Как уже было сказано, npm run serve поставляет содержимое папки public . Вторая опция, video , отключает для Cypress запись видео, поскольку в данном проекте нам это не понадобится.

Время создавать тест. В cypress/integration/screenshot.spec.js добавим:

В коде выше динамически создаются тесты, основанные на массиве routes . Тест создаст по одному изображению на каждый элемент .cypress-wrapper , который есть на странице.

Наконец, внутри package.json создадим команду для запуска тестов:

И здесь появляются два варианта: запускать Cypress в headless-режиме через npm run cypress run или воспользоваться Cypress Test Runner через npm run cypress open .

Вариант Headless

Вывод npm run cypress run должен быть похож на следующее изображение:

Тесты будут пройдены, и будут созданы пять изображений в папке /snapshots/screenshot.spec.js .

Вариант Test Runner

Через npm run cypress open откроется Cypress Test Runner, и вы сможете следить за тестами шаг за шагом.

Первую веху мы преодолели, так что давайте объединять текущую ветку с веткой master. Если хотите увидеть текущее состояние проекта, переходите прямо к моему пулл-реквесту.

Если вы запустите тест выше, чередуя Headless и Test Runner, то, возможно, заметите, что скриншоты отличаются.

На компьютерах с retina-дисплеем, вы можете получить retina-изображения (2x) через Test Runner, в то время как headless-режим не предоставляет скриншотов в высоком качестве.

Кроме того, важно отметить, что скриншоты могут отличаться в зависимости от вашей операционной системы.

В Linux и Windows, например, полоса прокрутки у приложений видима, а macOS скрывает полосу прокрутки.

Если содержимое на скриншоте не соответствует компоненту, у вас может быть (или отсутствовать) полоса прокрутки. Если ваш проект опирается на шрифты, включенные в ОС по умолчанию, скриншоты также будут отличаться в зависимости от среды.

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

Давайте начнем с создания новой ветки:

Cypress предлагает различные Docker-образы — с подробностями можно ознакомиться в их документации и блоге.

Для этого примера я выбрал образ cypress/included , который включает в себя Electron и готов к использованию.

Нам нужно внести два изменения: поменять baseUrl в файле cypress.json :

и команду test в файле package.json :

При запуске npm run test возникнет проблема:

Изображения немного отличаются, но почему? Давайте посмотрим, что находится внутри папки __diff_output__ :

Именно то, о чем я упоминал чуть раньше: несоответствия шрифтов! Компонент Button (кнопка) использует шрифт, установленный в ОС по умолчанию. Поскольку Docker работает внутри Linux, отрисованный шрифт не будет таким же, как тот, который стоит на macOS.

Так как мы перешли на Docker, эти скриншоты устарели. Время их обновить:

Пожалуйста, обратите внимание: я снабжаю тест-команду префиксом переменной окружения CYPRESS_updateSnapshots .

Вторая веха позади. На случай, если вам понадобится помощь, сравните ваш результат с моим пулл-реквестом.

Давайте сольем эту ветку с основной и двинемся вперед.

Наш следующий шаг — добавление тестов в CI. На рынке существуют различные CI-решения, но для этого руководства я обращусь к Semaphore.

Конфигурация проста, и ее можно адаптировать к другим решениям, таким как CircleCI или Github Actions.

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

Первый шаг — установка start-server-and-test. Как следует из названия пакета, он запустит сервер, дождется URL-адреса и затем выполнит тестовую команду:

Во-вторых, отредактируйте файл package.json :

В скрипте test мы добавляем переменную окружения CYPRESS_baseUrl . Это позволит динамически изменять базовый URL-адрес, используемый Cypress. Кроме того, добавим скрипт test:ci , который запустит только что установленный пакет.

И, наконец, Semaphore. Создайте файл .semaphore/semaphore.yml со следующим содержимым:

Давайте разберемся в этом подробнее:

Еще одна веха пройдена, пора делать слияние нашей ветки! По желанию просмотрите пулл-реквест, содержащий все файлы из этого раздела, и проверьте сборку внутри Semaphore.

Чтение выходных данных тестов в CI не очень дружелюбно по отношению к пользователю. На этом этапе мы интегрируем наш проект с cypress.io.

Следующие шаги основаны на документации Cypress.

Давайте начнем с того, что получим идентификатор проекта и ключ записи. В терминале создайте новую ветку и запустите:

Ранее я упоминал, что мы будем пользоваться Cypress внутри Docker. Но здесь мы открываем Cypress локально, так как это единственный способ интеграции с информационной панелью веб-сайта.

Внутри Cypress перейдем на вкладку Runs, нажмем кнопку Set up project to record (“Настроить проект для записи”) и выберем имя и настройку видимости. Мы получим projectId , который автоматически добавляется в файл cypress.json , и закрытый ключ записи. Вот видео этих шагов:

В Semaphore я добавил ключ записи в качестве переменной окружения CYPRESS_recordKey . Теперь давайте обновим тестовый скрипт с учетом этой переменной:

На этом практически все. В пулл-реквесте можно видеть интеграцию cypress.io в комментариях. Есть даже глубинная ссылка, которая ведет к их приборной панели и показывает все скриншоты. Посмотрите видео ниже:

Пришло время сделать последнее слияние и закончить на этом интеграцию.

Представьте, что мы работаем над изменением, которое влияет на заполнение кнопок: время проверить, будет ли Cypress улавливать разницу.

На примере веб-сайта давайте удвоим горизонтальное заполнение с 16px до 32px. Это довольно простое изменение, так как мы используем Tailwind CSS: px-4 заменяется на px-8 . Вот пулл-реквест.

Как и следовало ожидать, Cypress зафиксировал, что кнопка не соответствует скриншотам. Посетив страницу, мы можем проверить скриншот сломанного теста:

Файл diff показывает исходный скриншот слева, текущий результат справа, и их наложение — в середине. Есть также возможность загрузить изображение, чтобы лучше рассмотреть проблему:

Если это на самом деле не проблема, обновите скриншоты:

На сегодня все. Надеюсь, вы узнали, как с пользой применять Cypress, чтобы гарантировать, что никто не добавляет в проект неожиданные изменения.

Читайте также: