Karate vs Cucumber + RestAssured

В данной заметке мы постараемся сравнить инструменты для тестирования API, такие как: • Karate; • Cucumber + RestAssured.

Вот простое определение каждого инструмента: 1. Karate предоставляет свой DSL для составления последовательности вызовов веб-сервисов и проверки, что ответы сервисов соответствуют ожидаемым . 2. RestAssured помогает тестировать и проверять REST-сервисы в Java. 3. Cucumber позволяет обернуть ваш код тестов читабельными бизнес-спецификациями.

Более подробно на официальных сайтах: • Karate: https://github.com/intuit/karate; • RestAssured: http://rest-assured.io/; • Cucumber: https://cucumber.io/.

Мы не будем использовать много глубоких критериев и просто выберем более распространенные и общие сценарии использования для сравнения.

Итак, особенности использования Karate или Cucumber + RestAssured:

На основании этой таблицы можно сделать некоторые выводы об использовании рассматриваемых инструментов: 1. Оба поддерживают Gherkin. Это делает файлы с тестовыми сценариями читабельными для непрограммистов. 2. Karate поддерживает Gherkin-синтаксис. Но в то же время вы должны поместить все вызовы Java и JS-методов в фича-файлы. На основании этого читаемость сценариев сильно снижается. 3. Karate поддерживает повторное использование фича-файлов. У вас есть возможность вызывать один фича-файл из другого. Но в то же время, если для сценария требуются параметры, вы не можете использовать его отдельно — вы должны пометить его тегом игнорирования. Cucumber не поддерживает функцию повторного использования вообще. 4. Оба инструмента могут взаимодействовать с базой данных. Это хорошо, потому что часто необходимо получать тестовые данные и базы данных или проверять результат прохождения теста. 5. Управление состоянием теста — это частая задача, которую инженер по автоматизации тестирования должен решать, работая с инструментами BDD (в нашем случае, Cucumber). В обоих случаях мы должны создать собственный общий контекст переменных. Существование объекта, который хранит в себе «слишком много» или делает «слишком много» (God object) является анти-паттерном в программировании. 6. Karate позволяет нам не создавать классы с определениями шагов, как в Cucumber. Но на практике Karate скрывает только простые вещи (стандартные запросы, проверки). Если мы хотим сделать более сложные действия в рамках теста — придётся поместить эту логику в отдельный фича-файл для дальнейшего переиспользования или создать собственный Java-метод и вызвать его в нашем фича-файле. Такой подход, зачастую, выглядит нечитаемым. 7. Оба инструмента поддерживают подход тестирования на основе данных (data driven testing). Это позволяет нам использовать один и тот же тест с разными тестовыми данными. Это хороший момент для обоих инструментов. 8. Karate поддерживает нативное распараллеливание тестов (Runner.parallel). Во фреймворке Cucumber + RestAssured необходимо настраивать дополнительные плагины для параллельного запуска тестов.

Некоторые дополнительные пункты по поводу рассматриваемых инструментов: • Karate имеет встроенную поддержку JSON и XML и обеспечивает простую параметризацию теста в фича-файлах. При использовании Cucumber + Rest Assured вы должны реализовать эти функции самостоятельно; • Karate предоставляет большое количество встроенных возможностей по проверке полей ответа сервиса, например, проверка на соответствие регулярному выражению, что поле не содержит null или равно результату выполнения некоторой математической операции. При использовании Cucumber + Rest Assured подобные проверки необходимо реализовывать самостоятельно; • из-за абстракции Karate DSL очень сложно, а иногда и невозможно отладить нативные шаги Karate. Для отладки часто приходится пользоваться избыточным логированием; • Karate довольно проблематично корректно интегрировать с Report Portal https://github.com/reportportal/agent-java-karate. Интеграция Report Portal с Cucumber + Rest Assured намного проще; • фреймворк на основе Cucumber + RestAssured может иметь общую для всех BDD-фреймворков проблему — избыточность и дублирование логики шагов

Общий вывод

Оба инструмента выглядят неудобно для задач тестирования сложных API из-за дополнительного уровня абстракции с описанием поведенческих сценариев. Чистый код (Java + RestAssured) может быть гораздо более эффективным. Однако если стоит задача написания большого количества тестов с простыми запросами/ответами API, Karate может быть отличным выбором, так как предоставляет огромный набор уже реализованных методов вызова API и проверки формата ответов. Помимо этого, если нам нужно предоставить инструмент тестирования API, которым может пользоваться команда ручных тестировщиков или SCRUM-команда разработчиков без инженера по тестированию, то фреймворк Karate — лучшее решение, потому что он легко настраивается и уже содержит основные шаги и механизмы работы с API.