Мы также добились успеха с Cypress в моей нынешней организации. Одна мощная функция, которую мы использовали, — это cy.route(), которая позволяет нам отслеживать сетевые запросы к нашему API. Это полезно в двух случаях. Во-первых, если к конечной точке отправляется запрос GET для извлечения важных данных для отображения на странице, мы можем провалить тест до того, как будут предприняты какие-либо другие действия, если конечная точка не отвечает должным образом. Во-вторых, мы можем отслеживать POST, PUT или PATCH, которые отправляются в наш API при отправке формы.
В обоих этих случаях мы можем быстро сузить круг что из-за сбоя теста и перейти к почему. Кроме того, мы написали несколько пользовательских утверждений chai, которые регистрируют полезные данные о тестируемой http-транзакции. Например, если ответ возвращает код состояния 400, а мы ожидали 201, также полезно иметь больше данных об отправленном теле запроса, заголовках и теле ответа и т. д.
Используя это, мы можем внедрить часть нашего контрактного тестирования API в сквозную структуру. Это не замена отдельного набора контрактных тестов API, но это было полезно.
