Написание сквозных тестов стало намного проще с такими инструментами, как 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: начало работы.
Спасибо за чтение :)