Разметка директории была стандартной для проектов Java Maven / Cucumber JVM. Вообще-то Karate была основана на Cucumber JVM вплоть до версии 0.8.0. Интересно, что документация Karate рекомендует размещать feature-файлы в директорию src/test/java, а не в src/test/resources.

IDE

Документация Karate рекомендует использовать Eclipse или IntelliJ-IDEA для разработки тестов. Обе IDE предлагают поддержку для Junit и Cucumber, чем Karate может пользоваться не только для редактирования, но и для прогона тестов. Я бы пользовался IntelliJ-IDEA для серьезного тестирования.

Несмотря на это, для моего первичного знакомства я остановился на Visual Studio Code. Почему же?

• Быстро и просто
• Хорошая поддержка Java и Gherkin
• Есть менеджер файлов и встроенный терминал.

Вот как мой проект Karate выглядел в Visual Studio Code. Симпатично!

Примеры

Шаблонный проект включает примеры тестов в файле users.feature. Первый сценарий из файла, скопированный ниже, тестирует получение пользователей из JSONPlaceholder REST API:

Feature: sample karate test script

Background:
* url 'https://jsonplaceholder.typicode.com'

Scenario: get all users and then get the first user by id

Given path 'users'
When method get
Then status 200

* def first = response[0]

Given path 'users', first.id
When method get
Then status 200

Все, кто знаком с Cucumber, сразу же узнают знакомый формат Если/Когда/Тогда. Однако стандартные шаги Karate делают язык мощнее по сравнению с сырым Gherkin:

• Given-шаги создают запросы.
• When-шаги отправляют запросы.
• Then-шаги валидируют ответы.
• Catch-all –шаги дают дополнительные указания, например, задают переменные.

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

Прогон тестов

Так как я выбрал Maven и Visual Studio Code, то самый простой способ прогнать тесты, ничего не настраивая дополнительно – это командная строка с использованием "mvn test". Тесты-примеры поступают с файлом ExamplesTest.java, который прогоняет все feature-файлы в наборе, если обнаружен в ходе тест-фазы Maven. По умолчанию проект использует JUnit4, однако JUnit5 тоже поддерживается.

Прогон тестов публикует множество строк в консоли. Каждый запрос и ответ там отображаются. Снизу – финал успешного прогона файла users.feature:

Karate также умеет создавать полезные отчеты о тестировании. Проект по умолчанию генерирует отчеты JUnit, однако другие форматы, например, Cucumber, тоже доступны.

JUnit HTML-отчет показывает пошаговый лог для каждого сценария.

Полные запросы и ответы автоматически логируются, что очень помогает при дебаге.

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

Мои сценарии

Примеры – это здорово, но я хотел написать мои собственные сценарии для реальной веб-службы, чтобы получить практический опыт. Я создал тест для Recipe Puppy, поисковой системы, которая предоставляет ссылки на рецепты, если ввести туда ингредиенты:

Feature: Recipe Puppy

Background:
* url 'http://www.recipepuppy.com'

Scenario Outline: Get a recipe for <ingredient>

Given path 'api'
And params {i: '<ingredient>'}
When method get
Then status 200
And match response contains {results: '#array'}
And match response.results[*] contains
  """
  {
    title: '#string',
    href: '#string',
    ingredients: '#regex <ingredient>',
    thumbnail: '#string'
  }
  """

  Examples:
    | ingredient |
    | tomato     |
    | pepperoni  |
    | cheese     |

Вот что я обнаружил, создавая новый feature-файл:

• Шаблоны сценариев поддерживаются, но предпочитаются тесты, управляющиеся через данные.
• JSON-объекты можно использовать, как аргументы в шагах, а также как переменные.
• Синтаксис простой, но довольно продвинутый.
• Маркеры вроде #array поддерживают неточное совпадение, когда точные значения неизвестны.
• Многострочные JSON-выражения нуждаются в блоках цитирования.

Мой новый сценарий прошел так же успешно, как и примеры!

Автономный запуск

Создание тестов с использованием доменно-специфичного языка Karate не требует навыков разработки в Java, однако настройка полного проекта нуждается в них. К счастью, Karate предоставляет автономный JAR, который может запускать feature-файлы без каких-либо зависимостей или конфигурирования. Он просто берет пути к файлам, прогоняет их, и создает Cucumber-отчеты. Этот JAR – хорошая идея для тестировщиков, у которых нет солидных навыков программирования.

Этот отчет был сгенерирован после прогона моего теста для Recipe Puppy при помощи JAR.

Другие особенности

Несмотря на то, что проект довольно молод (создан в GitHub 7февраля 2017), у Karate множество приятных особенностей, которыми я еще не пробовал пользоваться:

• Параллельный запуск тестов
• Имитация сервлета
• Интерфейс для визуального дебага скриптов.
• Чтение файлов различных типов для задания переменных.
• Вызов feature-файла из другого feature-файла
• Вызов кода JavaScript
• Вызов кода Java
• Использование сценариев вроде тестов производительности Gatling.

Участники проекта также экспериментируют с тем, чтобы расширить Karate до браузерных, мобильных и десктопных интерфейсов с использованием Selenium WebDriver.

Анализ

В общем и целом это отличный инструмент для тестирования веб-служб. Он берет на себя все детали программного внедрения, и тестировщики могут сконцентрироваться на тестировании. Его синтаксис четок, ясен и гибок. Его встроенная поддержка объектов JSON делает работу с запросами и ответами естественной. Документация в GitHub выше всяких похвал. Любой тестировщик REST API должен внимательно посмотреть на Karate.

Несмотря на то, что в Karate используется синтаксис, похожий на Gherkin, это не настоящий BDD-фреймворк. Он просто извлекает пользу из достоинств Cucumber – читабельности, возможности переиспользования, инструментария – чтобы облегчить тестирование веб-сервисов. Я давно говорил, что одно из лучших решений для преодоления проблем автоматизаци – это создание доменно-специфического языка тестирования, которое автоматически берет на себя низкоуровневые детали (см. статью). Проект Karate подтверждает это заявление. DSL Karate работает скорее как язык тестирования, а не как бизнес-ориентированный язык спецификаций. Его ключевые слова Gherkin просто дают пользователям структуру и узнаваемость шагов. И то, что Karate – не "чистая BDD", вполне ОК – просто спросите автора проекта.

Учитывая все вышесказанное, я бы сказал, что тестировщику необходимы базовые навыки программирования, чтобы пользоваться Karate. Запуск тестов требует настройки Java, а feature-файлы – это просто красивые тест-сценарии. Плюс к этому API у веб-сервисов – это код по определению.

Я буду с интересом следить за развитием проекта, особенно если туда добавят шаги, основанные на WebDriver.

Ссылки:

• The Karate GitHub project
• REST API Testing with Karate (Baeldung)
• Karate a Rest Test Tool – Basic API Testing (Joe Colantonio)
• Karate framework: REST API testing made easy! (Mohammed Aboullaite)