Отказ от ответственности: эта статья не является пошаговым руководством по Cypress и подробным объяснением API Cypress, а скорее освещает результаты и выводы после использования Cypress в качестве инструмента E2E для приложения React, используемого в производственной среде.

Почему тесты так важны?

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

Мой следующий вопрос о том, как они обеспечивают правильную работу новой функции. В основном говорят, что проверяют сами или QA.

Другими словами, каждый разработчик использует тесты, будь то автоматические или ручные. На конференции WeAreDevelopers в 2017 году ведущий рассказал о тестировании и сделал следующее заявление:

Каждый раз, тестируя вручную, вы зря тратите время
Presenter @ WAD 2017

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

Если мы сравним сложность и стоимость обслуживания для разных типов тестов, мы сможем получить следующую диаграмму (не принимайте линейность диаграммы как должное, там может быть некоторые перекрытия)

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

  • Нестабильность - тесты E2E могут проходить и произвольно терпеть неудачу в одних и тех же условиях из-за задержки в сети или других асинхронных компонентов.
  • Поведение пользователя - тесты E2E нацелены на моделирование поведения пользователя, которое может быть сложно смоделировать.
  • Динамическая модель DOM. Базовая модель DOM может быть довольно динамичной, особенно для одностраничного приложения (SPA). Элементы могут быть скрыты от пользователя, но уже существуют в DOM и т. Д.

Давайте вкратце обсудим, чего мы хотим достичь с помощью тестов E2E:

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

Тестирование на TourRadar

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

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

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

Определение критических путей

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

Возвращаясь к нашему примеру с процессом адаптации, мы определили следующие критические пути, для которых мы создали тесты:

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

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

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

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

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

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

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

Настраивая псевдонимы для сетевых запросов, мы не можем дождаться только доступности элементов DOM, но и останавливать выполнение нашего теста до тех пор, пока сетевой запрос не завершится.

Cypress Заключение

После того, как мы использовали Cypress более полугода, мы хотели сделать вывод и обобщить наши выводы о Cypress.

Плюсы

  • Легко отлаживать - с помощью пользовательского интерфейса и браузера
  • Универсальное решение - установка или другие инструменты не требуются.
  • Дизайн компонентов. Подумав о том, как можно запрашивать ваш компонент, мы реорганизовали довольно много наших компонентов (используя правильный идентификатор в сочетании с метками формы).
  • Без косвенного обращения - тесты выполняются непосредственно в браузере, и к собственным API-интерфейсам браузера можно получить прямой доступ.
  • Скорость. Тесты выполняются чертовски быстро 🏎

Минусы

Нейтрально: компания, стоящая за Cypress, зарабатывает деньги, предлагая платную панель управления, которая предоставляет историю всех тестовых запусков. Мы пытались интегрировать наш E2E-тест в наши конвейеры Bitbucket, но, как только тест не удался, было трудно понять точную причину - здесь вступает в игру панель инструментов, которая, кстати, все еще бесплатна (!), Пока находится в стадии бета-тестирования.

Подводя итоги…

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

В TourRadar мы используем смесь Selenium и Cypress, так как Cypress все еще не поддерживает кроссбраузерные функции. Настроить Cypress с помощью дополнительных помощников по тестированию действительно легко, чтобы он оставался СУХИМ. Взаимодействие с компонентами React / элементами DOM может быть сложной задачей, но Cypress может помочь сделать это намного проще. Мы закончили тем, что увеличили CommandTimeout по умолчанию до 10 секунд, так как тесты имеют тенденцию к самопроизвольному сбою из-за тайм-аута команды.

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

Эта презентация основана на моем выступлении на встрече ViennaReact Meetup в июне 2018 года:

👋 Хотите стать частью растущего стартапа в сфере туристических технологий? Ознакомьтесь с нашими открытыми вакансиями здесь! 👋