Давайте погрузимся в Cypress для непрерывного тестирования — Smashing Magazine

Краткое описание ↬

Сквозное тестирование — это для вас болезненная тема? В этой статье Рамона Шверинг объясняет, как провести сквозное тестирование с помощью Cypress и сделать его не таким утомительным и дорогим для себя, а вместо этого забавным.

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

Однако сквозное тестирование действительно имеет некоторые подводные камни которые вызывают беспокойство:

• Сквозные тесты проходят медленно и, таким образом, представляют собой серьезное препятствие для любой стратегии непрерывной интеграции и непрерывного развертывания (CI / CD). Не только это, но представьте, что вы завершаете задачу, функцию или любую другую реализацию — ожидание выполнения теста может истощить всеобщее терпение.
• Такие сквозные тесты сложно поддерживать, они подвержены ошибкам и дороги во всех отношениях из-за усилий по отладке. Причиной этого могут быть различные факторы. Ваш тест должен быть помощником, а не помехой.
• Самый большой кошмар для разработчиков — это нестандартный тест, который выполняется одинаково, но приводит к другим результатам. Это похоже на «Heisenbug», который возникает только в том случае, если вы не измеряете тестируемое приложение, то есть не смотрите на него.

Но не беспокойтесь: вам не нужно поддаваться этим ловушкам. Давайте посмотрим, как предотвратить многие из них . Однако я не буду просто обещать луну и не доставлю. В этом руководстве мы вместе напишем несколько тестов, которые я опубликовал для вас в репозитории GitHub. Таким образом, я надеюсь показать вам, что конечное тестирование может быть интересным! Приступим.

Что такое сквозные тесты?

Когда я говорю о сквозном (или E2E) тестировании, я люблю называть его «основанным на рабочем процессе». Эта фраза хорошо описывает сквозное тестирование: оно имитирует реальные рабочие процессы пользователя и должно включать как можно больше функциональных областей и частей технологического стека, используемых в приложении. В конце концов, компьютер притворяется покупателем и пытается вести себя как настоящий пользователь. Эти тесты лучше всего подходят для приложения постоянной нагрузки ко всей системе вашего приложения и, таким образом, являются отличной мерой для обеспечения качества когда присутствует весь стек приложения.

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

Это правильный вопрос. Один из возможных ответов можно найти в метафоре: пирамида автоматизации тестирования, впервые представленная Майком Коном и дополнительно уточненная Мартином Фаулером, показывает как сделать тестирование эффективным . На самом низком уровне пирамиды мы находим быстрые и дешевые модульные тесты, а наверху — трудоемкие и дорогие UI-тесты (сквозное тестирование).

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

Мое путешествие на Кипарис

Когда я начал учиться писать сквозные тесты, я использовал Mink, библиотеку PHP, поверх Behat, среды разработки, ориентированной на сценарии (BDD). Я начал использовать Selenium со всеми его достоинствами и недостатками. Поскольку моя команда начала много работать с Vue.js, мы перешли на платформу тестирования на основе JavaScript, чтобы обеспечить безупречную интеграцию и совместимость. Тогда мы выбрали Nightwatch.js, поэтому я построил наш новый набор тестов с нуля.

В то время, мы часто сталкивались с проблемами совместимости . Вы могли бы назвать это адом зависимостей — не говоря уже обо всех ограничениях, которые мы видели в Selenium, а затем и в WebDriver.

• В нашей команде нам не удалось определить версию нашего CI для Chrome. Поэтому, если были выпущены обновления для Chrome, Nightwatch.js не был достаточно быстрым, чтобы быть совместимым, что привело к множеству сбоев в наших конвейерах тестирования.
• Число причин нестабильных тестов на стороне тестирования начало расти, поскольку возможности ожидания Nightwatch.js не оптимально соответствовали нашему продукту.

Итак, мы решили заново создать наш набор тестов. Посетив неконференцию, я открыл для себя Cypress.

Cypress — это комплексная среда тестирования, которая не использует Selenium или WebDriver. Инструмент использует Node.js для запуска браузера под особым контролем. Тесты в этой структуре выполняются на уровне браузера, а не только при удаленном управлении. Это дает несколько преимуществ.

Вкратце, вот причины, по которым я выбрал этот фреймворк:

• Отличные возможности отладки
  Средство выполнения тестов Cypress может вернуться в любое состояние приложения с помощью снимков. Итак, мы можем напрямую видеть ошибку и все шаги до нее. Кроме того, предоставляется полный доступ к инструментам разработчика Chrome (DevTools), а клики полностью регистрируются.
• Лучшие способы ожидания действий в тесте или пользовательском интерфейсе или в ответах от API
  Cypress обеспечивает неявное ожидание, поэтому нет необходимости в соответствующих проверках. Вы также можете заставить тест ждать анимации и ответов API.
• Тесты написаны на JavaScript
  Это сокращает время обучения написанию тестов. Программа запуска тестов Cypress имеет открытый исходный код, поэтому она соответствует нашей продуктовой стратегии.

Однако эта статья является руководством, поэтому давайте остановимся на этой общей информации и приступим к делу.

Начало работы

Установите и запустите Cypress

Начнем с нуля. В своих разговорах о Cypress я обычно начинаю с создания нового каталога с помощью mkdir а затем сразу же устанавливаю Cypress. Самый простой способ установки показан на этом чертеже:

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

  пряжа добавить кипарис --dev
 

Альтернативой является прямая загрузка с использованием папок ZIP, которые предоставляет Cypress. Вот и все! После завершения установки все готово.

Есть два способа запустить тесты Cypress. Во-первых, запустив Cypress в консоли и запустив тесты в автономном режиме:

  ./ node_modules / .bin / cypress run
 

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

  ./ node_modules / .bin / cypress open
 

Эта команда открывает средство запуска тестов. Когда вы впервые открываете Cypress, вы увидите этот интерфейс:

Cypress предоставляет некоторые предварительно записанные образцы тестов, чтобы продемонстрировать свои возможности и дать вам некоторые отправные точки — это причина того, что тесты доступны. Давайте пока их проигнорируем, потому что мы хотим вскоре написать свои собственные. Тем не менее, помните об этой области «Интеграционные тесты», потому что в ней будет много волшебства, которое произойдет позже.

Первое впечатление от строения Кипариса

Пришло время открыть наш недавно созданный проект в выбранной интегрированной среде разработки (IDE). Если вы перейдете в эту папку, вы увидите следующую структуру теста:

  пример разрушения
  └── кипарис
      └── светильники
      └── интеграция
      └── плагины
      └── поддержка
  └── cypress.json  

Давайте рассмотрим эти папки:

• фикстуры
  Здесь вы найдете фиксированные тестовые данные, не имеющие отношения к другим объектам. Таким образом, здесь не хранятся идентификаторы, которые могут меняться в зависимости от местного штата.
• интеграция
  Фактические тесты вы найдете здесь.
• плагины
  Здесь вы можете расширить Cypress с помощью существующих или собственных плагинов Cypress.
• поддержка
  Здесь вы можете расширить сам Cypress. Здесь находятся ваши собственные команды и помощники.
• cypress.json
  Измените здесь конфигурации, в том числе для среды.

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

Выберите тестовый пример

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

На мой взгляд, термин «на основе рабочего процесса» является ключевым : мы бы выбрали тестовые примеры на основе типичных пользовательских историй. Однако из-за времени выполнения не рекомендуется охватывать все доступные рабочие процессы. Следовательно, нам нужен способ расставить приоритеты для наших тестовых примеров.

В моей команде у нас было несколько критериев для нашего проекта. Тестовый пример должен:

• охватывают наиболее общие и наиболее часто используемые рабочие процессы функции, такие как операции CRUD (термин «счастливый путь» достаточно хорошо описывает эти рабочие процессы);
• использовать анализ рисков, охватывающий рабочие процессы с тестами E2E, которые наиболее уязвимы (т.е. там, где ошибки могут причинить наибольший ущерб);
• избежать дублирования покрытия;
• не обязательно использовать, если модульные тесты более подходят (используйте тест E2E, чтобы проверить реакцию вашего программного обеспечения на ошибку, а не саму ошибку).

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

Пример:

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

Пример: поиск моих статей в Smashing Magazine

Я хочу написать тест для этого веб-сайта Smashing Magazine. Я не могу гарантировать, что этот тест будет актуальным всегда, но будем надеяться, что он продлится долго. В любом случае вы сможете найти этот пример в репозитории GitHub.

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

В папке интеграции мы начнем с создания нового файла. Назовем его find-author.spec.js . Суффикс .spec означает «спецификация». В терминах теста это относится к техническим деталям данной функции или приложения, которым должно соответствовать ваше приложение.

Чтобы превратить этот пустой файл JavaScript в домашний тестер, мы начнем с того, что дадим ему его структуру. Мы воспользуемся методом описать . description () или context () используется для хранения и организации тестов. Другими словами, этот метод служит рамкой для наших тестов. Таким образом, наш тестовый файл будет выглядеть так:

  // find-author.spec.js
описать ('Найти авторов при разгроме', () => {
  // ...
});  

Следующим шагом будет создание самого теста. Мы будем использовать метод it . it () или Specify () используется для представления фактического теста. Как видите, мы можем записать несколько тестов в один файл, что дает отличные возможности структурирования.

  // find-author.spec.js
описать ('Найти авторов при разгроме', () => {
  it ('Найдите автора Рамону Шверинг', () => {
    cy.log («Это наш новый тест»);
  });
});  

Маленькая подсказка : Если вы знакомы с Mocha, вы могли заметить некоторые сходства. Cypress построен на основе Mocha, поэтому синтаксис такой же.

Хорошо, поехали. Если мы запустим наш тест в средстве запуска тестов Cypress, мы заметим, что Cypress откроет браузер для запуска теста. Этот браузер показан на снимке экрана ниже:

Поздравляем! Мы написали свой первый тест! Конечно, это мало что значит. Нам нужно продолжать. Давайте наполним наш тест жизнью.

Наполните испытание жизнью

Что нужно сделать в первую очередь при тестировании веб-сайта? Хорошо, нам нужно открыть сайт. Мы можем сделать это с помощью команды Cypress. Вы можете спросить, что это за команда?

Работа с командами

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

Итак, наша первая команда будет переходить на веб-сайт — smashingmagazine.com . Эта команда называется визит .

С его помощью наш тест будет выглядеть так:

  // find-author.spec.js
описать ('Найти авторов при разгроме', () => {
  it ('Найдите автора Рамону Шверинг', () => {
    cy.visit ('https://www.smashingmagazine.com/');
  });
});  

Я часто использую одну команду, и вы тоже будете ее использовать. Он называется get :

  cy.get ("селектор");  

Эта команда возвращает элемент в соответствии с его селектором — аналогично jQuery $ (…) . Итак, вы должны использовать эту команду, чтобы найти части, с которыми нужно взаимодействовать. Обычно вы используете его для запуска цепочки команд. Но подождите — что подразумевается под цепочкой команд?

Как упоминалось в начале этой статьи, все тесты и все, что с ними связано, написано на JavaScript. Вы можете поместить команды в тесты (то есть операторы) в цепочку (другими словами, в цепочку). Это означает, что команды могут передавать тему (или возвращаемое значение) команды следующей команде, как мы знаем из многих систем тестирования.

Хорошо, мы начнем цепочку команд с команды get . Чтобы найти элемент с get нам нужно сначала найти его селектор. Очень важно найти уникальный селектор, потому что в противном случае Cypress вернет все совпадающие элементы; так что помните об этом и избегайте этого, если это произойдет непреднамеренно.

Взаимодействие с элементами

В Cypress есть функция, которая поможет вам найти селекторы элементов, с которыми вы хотите работать. Эта функция называется «Площадкой для выбора», и она помогает вам обнаружить уникальные селекторы компонента или увидеть все совпадающие элементы для селектора или текстовой строки. Итак, эта функция может очень помочь вам в этой задаче. Чтобы включить его, просто щелкните значок перекрестия в заголовке пользовательского интерфейса теста, а затем наведите указатель мыши на нужный элемент:

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

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

В этом случае я бы вернулся к DevTools браузера, чтобы найти свои уникальные селекторы. Возможно, вы знакомы с этими инструментами; в моем случае я часто выбираю для этой цели Chrome. Однако другие поддерживаемые браузеры могут предоставлять аналогичные функции. Процесс похож на Selector Playground, за исключением того, что мы используем функции DevTools на вкладке «Элемент».

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

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

Наш тест как последовательность команд

Хорошо, вернемся к нашему тесту. В нем мы хотим отобразить наш рабочий процесс:

«Я, как пользователь, буду искать статью автора и перейду на сайт автора через область ссылок в одной из его статей».

Мы воспроизведем действия, которые пользователь предпримет с помощью команд. Я вставлю ниже готовый тест с комментариями, которые объяснят шаги:

  // find-author.spec.js
it ('Найдите автора Рамону Шверинг', () => {
  // Открываем сайт
  cy.visit ('https://www.smashingmagazine.com');

  // Вводим имя автора в поле поиска
  cy.get ('# js-search-input'). type ('Рамона Шверинг');

  // Перейти к статье автора
  cy.get ('h2> a'). first (). click ();

  // Открываем страницу автора
  cy.get ('. author-post__author-title'). click ();
});
 

В этом примере рассматривается рабочий процесс, который мы хотим протестировать. Cypress выполнит этот тест. Итак, пора ли сказать «Поздравления»? Мы наконец закончили писать наш первый тест?

Пожалуйста, присмотритесь . Cypress выполнит его, но он будет делать только то, что ему подсказывает тест, то есть то, что вы написали. Если вы запустите его в средстве выполнения тестов, вы можете увидеть, прошел ли он, но не в том случае, если вы запускали его без головы. С помощью этого теста мы знаем только, может ли Cypress успешно выполнять наши команды, а не то, попали ли мы на сайт автора. Итак, нам нужно научить наш тест определять это.

Работа с утверждениями

Второй тип операторов заботится об описании желаемого состояния пользовательского интерфейса — то есть, должно ли что-то существовать, быть видимым или больше не быть видимым. Утверждения в Cypress основаны на утверждениях Чай и Синон-Чай, что заметно в синтаксисе.

Помните, что мы хотим проверить, находимся ли мы на странице профиля автора — в этом примере я. Итак, нам нужно добавить утверждение именно для этого:

  // find-author.spec.js
it ('Найдите автора Рамону Шверинг', () => {
  // Открываем сайт
  cy.visit ('https://www.smashingmagazine.com');

  // Вводим имя автора в поле поиска
  cy.get ('# js-search-input'). type ('Рамона Шверинг');

  // Перейти к статье автора
  cy.get ('h2> a'). first (). click ();

  // Открываем страницу автора
  cy.get ('. author-post__author-title'). click ();

  // Проверяем, находимся ли мы на сайте автора
  cy.contains ('. author__title', 'Ramona Schwering'). Should ('be.visible');
});
 

Хорошо, теперь мы написали полезный тест. Итак, да, поздравляю с написанием вашего первого теста … даже если он еще не идеален.

Давайте сделаем наш тест красивым

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

Не торопитесь

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

Что бы сделал пользователь, если бы он захотел увидеть веб-сайт, который все еще загружается? Скорее всего, они будут ждать, пока некоторые части веб-сайта станут видимыми (то есть загруженными), а затем будут с ними взаимодействовать. В нашем тесте мы хотим точно имитировать это: мы хотим дождаться изменений в пользовательском интерфейсе, прежде чем начинать взаимодействие . В большинстве случаев мы ограничиваем это поведение необходимыми нам элементами, таким образом используя утверждения для этих элементов.

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

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

  // find-author-assertions.spec.js
// Открыть сайт
cy.visit ('https://www.smashingmagazine.com');

// Убедитесь, что сайт полностью загружен
cy.get ('. заголовок-контент'). должен ('быть.visible');

// Вводим имя автора в поле поиска
cy.get ('# js-search-input'). type ('Рамона Шверинг');  

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

Чтобы не попасть в ловушку нестандартных тестов, я хотел бы дать вам последний совет: никогда не используйте фиксированное время ожидания, например cy.wait (500) или подобное.

Ответы API — ваши друзья

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

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

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

Давайте применим это к нашему тесту. Прежде всего, нам нужно определить маршрут, которого мы хотим ждать позже. Для этого мы можем использовать команду перехват . Я бы поискал по запросу, предоставив нужные мне данные — в данном случае результаты поиска.

Чтобы упростить этот пример, я буду использовать подстановочный знак для URL. После этого я буду использовать псевдоним, чтобы Cypress мог в дальнейшем работать с этим маршрутом.

  // find-author-hooks.spec.js
// Устанавливаем маршрут для работы с
it ('Найдите автора Рамону Шверинг', () => {

  // Маршрут, чтобы ждать позже
  cy.intercept ({
    url: '* / indexes / smashingmagazine / *',
    метод: 'POST'
  }). as ('поиск'); // С этим псевдонимом Cypress снова найдет запрос

  // ...
 

В Cypress все определенные маршруты отображаются в начале теста. Так что я бы тоже хотел поставить эти команды перехвата в начало моего теста.

Теперь мы можем использовать этот псевдоним маршрута в утверждениях. Самый простой способ сделать это — использовать команду Cypress ’ wait непосредственно с псевдонимом, упомянутым ранее. Однако использование только этой команды привело бы к ожиданию ответа независимо от его результата . Даже коды ошибок, такие как 400 или 500, будут считаться пройденными, тогда как ваше приложение, скорее всего, сломается. Поэтому я бы порекомендовал добавить еще одно утверждение вроде этого:

  // find-author-hooks.spec.js
// Позже: утверждение кода статуса поискового запроса
cy.wait ('@ поиск')
   .its ('response.statusCode'). should ('equal', 200);  

Таким образом, мы можем дождаться данных программного обеспечения, изменений и т. Д. С точностью, не теряя времени и не сталкиваясь с проблемами, если приложение сильно нагружено. Опять же, вы можете найти полный файл примера в моем репозитории на GitHub.

Настройка Cypress

Я упустил одну маленькую деталь. Если вы внимательно посмотрите на полный тестовый пример, он немного отличается от тех, которые мы использовали здесь в этом руководстве.

  // Кипарисовик
описать ('Найти автора при разборе', () => {
  beforeEach (() => {
    // Открыть сайт
    cy.visit ('https://www.smashingmagazine.com');
  });

// ...
 

Я использую только косую черту, чтобы открыть веб-сайт Smashing Magazine. Как это работает? Что ж, использование этой команды таким образом приведет к переходу к baseUrl наших тестов. baseUrl — это значение конфигурации, которое можно использовать в качестве префикса для URL-адреса команды cy.visit () или cy.request () . Среди других значений мы можем определить это значение в файле cypress.json . Для нашего теста мы установим baseUrl следующим образом:

  // cypress.json
{
  "baseUrl": "http://www.smashingmagazine.com"
}  

Достойное упоминание: Крючки

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

  // Кипарисовик
описать ('Крючки', function () {
  перед (() => {
    // Выполняется один раз перед всеми тестами
  });

  after (() => {
    // Запускается один раз после всех тестов
  });

  beforeEach (() => {
    // Запускается перед каждым тестом
  });

  afterEach (() => {
    // Запускается после каждого теста
  });
});  

We want to fill our test file with more than one test, so we should look for common steps that we want to execute before or after them. Our first line is a case in point, being the visit command. Assuming we want to open this website before each of these tests, a beforeEach hook in our example would look like this:

// Cypress
describe('Find author at smashing', () => {
  beforeEach(() => {
    // Open website
    cy.visit('https://www.smashingmagazine.com');
  });

  //...

I frequently use this in my daily work to ensure, for example, that my application is reset to its default state before the testthus isolating the test from other tests. (Never rely on previous tests!) Run your tests in isolation from each other to maintain control over the application’s state.

Each test should be able to run on its own — independent of other tests. This is critical to ensuring valid test results. For details on this, see the section “Data We Used to Share” in one of my recent articles. For now, refer to the complete example on GitHub if you want to see the entire test.

Conclusion

In my opinion, end-to-end tests are an essential component of CI, keeping the quality of applications at a high level and at the same time relieving the work of testers. Cypress is my tool of choice for debugging end-to-end tests quickly, stably, and efficiently, and for running them parallel to any pull request as part of CI. The learning curve is gentle if you’re already familiar with JavaScript.

I hope I’ve been able to guide you a bit and given you a starting point to write Cypress tests and some practical tips to get started. Of course, all code examples are available in the GitHub repository, so feel free to take a look.

Of course, this is only a starting point; there are many more things to learn and discuss regarding Cypress tests — I’ll leave you with some suggestions on what to learn next. With this in mind, happy testing!

Resources