Написание сквозных тестов стало намного проще с такими инструментами, как Cypress и TestCafe. Эти две библиотеки очень похожи. Оба они позволяют имитировать HTTP-запросы, хотя и немного по-разному. У них обоих есть API на основе обещаний, хотя у Cypress есть собственное «обещание».

Я хотел собрать статью, показывающую, как выглядит имитация HTTP-запроса в обеих средах, и объяснять, почему вы можете захотеть использовать эту практику. Я также хотел показать вам, почему нельзя использовать async / await для тестов Cypress.

Написание тестов: TestCafe vs Cypress

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

В TestCafe этот тест мог бы выглядеть так:

Этот же тест в Cypress будет выглядеть так:

Обещания на кипарисе

Вы могли заметить, что я не использую async / await с тестами Cypress. К сожалению, это компромисс при использовании Cypress. Команды cy не возвращают фактических обещаний, хотя вы можете использовать .then (…) для каждой команды. Возвращаемое «обещание» - это объект Chainer, который является оболочкой реального обещания. Они выбрали этот дизайн, чтобы сделать Cypress более детерминированным и стабильным, поскольку обычные JS-обещания не имеют концепции повторных попыток или возможности повторных попыток.

Из документов:

Cypress API не является точной реализацией обещаний 1: 1. У них есть качества, похожие на обещания, но есть важные различия, о которых следует знать.

1. Вы не можете участвовать в гонке или запускать несколько команд одновременно (параллельно).

2. Вы не можете «случайно» забыть вернуть или связать команду.

3. Вы не можете добавить обработчик ошибок .catch к неудачной команде.

Обратной стороной является то, что я не могу делать что-то вроде:

Вместо этого ваш код будет выглядеть ближе к этому:

Это должно быть хорошо знакомо, так как до async / await все наши обещания были написаны таким образом.

Мокинг HTTP-запросов

И TestCafe, и Cypress предоставляют способ имитировать HTTP-запросы в вашем тесте. Это может ускорить выполнение тестов, поскольку вам не придется ждать реальных ответов сервера, что иногда может занять некоторое время, в зависимости от того, что делает ваше приложение. У вас все еще должно быть несколько тестов, которые зависят от фактических ответов сервера, например, для проверки потока входа в систему. Но при тестировании более детальной функциональности вы должны имитировать некоторые свои запросы. Я знаю, это звучит странно, но я думаю об этом, когда сейчас тестирую пользовательский интерфейс, а не API. Скорее всего, у вас уже есть тесты для вашего API, и вам не нужно тестировать его дважды. Вы можете спросить: «А что, если модель API изменится? Теперь мой тест не провалится? ». Если API изменяется, это, скорее всего, означает, что ваш пользовательский интерфейс, который обрабатывает ответы / запросы, также должен измениться, что означает, что вам, вероятно, все равно придется обновить свои тесты.

Если вас все еще беспокоит насмешка над HTTP-запросами, НЕ ОБЯЗАТЕЛЬНО этого делать. Вы и ваша команда сами решаете, что принесет вам наибольшую уверенность в ваших тестах.

Мокинг в TestCafe

Чтобы имитировать HTTP-запросы в TestCafe, вы должны использовать конструктор RequestMock «.

Затем импортируйте макет в свой тест и используйте ловушку fixture или test под названием requestHooks:

Вы также можете связать несколько запросов и ответов на макет:

Мокинг в Cypress

Ответы на заглушки в Cypress немного отличаются. Чтобы ваши тесты начали заглушать указанные запросы, сначала вам нужно вызвать cy.server (), чтобы включить его. Чтобы сообщить серверу, какие запросы к заглушке и какой ответ возвращать, вы вызываете cy.route (‹options›).

Заявление об ограничении ответственности: cy.route не будет работать с новым API fetch . См. This github issue для получения дополнительной информации.

Вы также можете пропустить объект маршрута и вместо этого использовать параметры:

Светильники Cypress

У Cypress есть идея «светильников«. В отличие от TestCafe, фикстуры Cypress - это объекты JSON, которые содержат данные, которые вы хотите использовать в ложном ответе. Это очень полезно, поскольку иногда API может возвращать сложные данные, и хранение их в отдельном файле позволяет сохранить ваш файл спецификации в чистоте. Поэтому вместо того, чтобы указывать встроенный ответ в методе `cy.route`, вы можете указать `прибор`, который будет использоваться. Все, что вам нужно сделать, это создать новый файл .json в каталоге / cypress / fixtures /.

Вывод

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

Если вы только начинаете заниматься сквозным тестированием, ознакомьтесь с моим курсом по Pluralsight Сквозное веб-тестирование с TestCafe: начало работы.

Спасибо за чтение :)