
Тестирование сетевых приложений разделяется на несколько взаимосвязанных этапов и значительно зависит от корректности работы API. Нередко API публикует большое количество методов, манипулирующих объектами хранилища данных, часть из которых защищено механизмами авторизации. Тесты включают в себя последовательность операций по созданию-изменению-удалению объектов и могут состоять из большого количества запросов, которые предпочтительно проверять без участия тестировщика. В этой статье мы обсудим различные подходы к автоматизации тестов API с использованием Postman, Rest Assured и Karate DSL.
Начнем мы с наиболее известного инструмента для взаимодействия с API - Postman. Обычно он используется для ручного выполнения запросов к API. При создании запроса могут использоваться переменные и окружение (определяются для коллекции или отдельного запроса). Но также сейчас возможно определение сценарных тестов с использованием встроенного интерпретатора, который может работать с преднастроенным объектом pm для извлечения значения переменных и выполнения запросов.
Создадим новое рабочее пространство (File -> New -> Workspace) и коллекцию (File -> New -> Collection). Обратите внимание, что при создании коллекции доступна вкладка Tests, где определяется сценарий, который будет выполняться после каждого запроса в коллекции.

Для выполнения запросов используется метод pm.sendRequest(url, function(err, response) { ... });, где в функцию передает объект с информацией об ответе сервере или объект описания ошибки. Для проверки выполнения условия можно использовать функцию pm.test("message", function () { выражение })
, внутри которого может находиться pm.expect()
для проверки условия внутри теста. Выражение записывается в виде фразы <объект>.to.<условие>.<ожидаемое значение>
, например, response.to.have.status(200)
или except(response.text()).to.eql('OK')
. Содержимое ответа может быть извлечено из response.text() или response.json() и проверено через pm.test
/ pm.expect
. Также есть доступ к переменным окружения (pm.environment), переменным коллекции (pm.collectionVariables
), локальным переменным (pm.variables
). В остальном код сценария может использовать все возможности JavaScript (функции, условные операторы, циклы, ...), в том числе вывод сообщений в консоль (она доступна в Postman через меню View -> Show postman console
).
При определении запроса все тесты запускаются после выполнения запроса. При этом сценарий запроса может сохраняться промежуточные значения в pm.environment
и передавать их в следующий запрос из коллекции или группы. Результаты запроса доступны в pm.response
.
Для запуска тестов в контекстном меню коллекции необходимо выбрать Run collection, указать количество итераций и промежуток между ними. Результатом выполнения будет информация об итогам выполнения запросов в итерациях и отчет об успешности прохождения.
Для проверки создадим простой тест для Date Nager API (возвращает информацию о праздниках во многих странах мира). Для получения JSON-ответа обратимся к адресу https://date.nager.at/api/v3/publicholidays/2017/RU и проверим наличие праздника "Новый год" в ответе. Создадим GET-запрос к адресу и во вкладке Tests добавим следующий код:
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
pm.test("Response time is less than 400ms", function () {
pm.expect(pm.response.responseTime).to.be.below(400);
});
pm.test("Response have new year", function() {
const responseJson = pm.response.json();
pm.expect(responseJson[0].localName).to.eql("Новый год");
});
После запуска запроса (или всей коллекции) получим результат выполнения:

Для обращения к методам, защищенным токеном авторизации, можно использовать привычные способы управления заголовками запроса в Postman.
Теперь перейдем к более специализированным инструментам и поговорим про Rest Assured. Код для Rest Assured создается на Java, каждый тест - это отдельная функция с аннотацией @Test, которая состоит из двух частей:
when() - цепочка вызовов, создающая необходимый контекст, например, get("url")
then() - цепочка проверок (statusCode проверяет код ответа, body("path", equalTo("значение") проверяет значение поля json-объекта или XML-структуры).
Например, наш тест в Rest Assured выглядел бы так:
@Test
public void testNewYear() {
when().get("https://date.nager.at/api/v3/publicholidays/2017/RU").
then().statusCode(200).body("[0].localName", equalTo("Новый год"))
}
Главное преимущество RestAssured в том, что она является полноценной java-библиотекой и позволяет выполнять сложную обработку полученных данных, а также встраиваться в существующие Java-Kotlin приложения (непосредственно в задачу запуска автоматических тестов, например через JUnit).
Последняя библиотека, которую мы сегодня посмотрим - Karate DSL. Ее возможности обширны и выходят далеко за рамки сценарного тестирования API, но сейчас мы обсудим только возможности по созданию тестов API. Сценарий для Karate DSL создается в виде текстового документа, определяющего спецификацию теста из выражение Given (определение переменных), When (определение запроса), Then (условия проверки). В нашем случае описание могло бы выглядеть следующим образом:
Scenario: Test Date Nager API
Given url 'https://date.nager.at/api/v3/publicholidays/2017/RU'
When method get
Then status 200
And match response[0].localName == 'Новый год'
Тест может быть интегрирован в JUnit, а также выполнен через автономный jar-файл или через расширение Visual Studio Code. Для запуска теста достаточно передать название feature-файла (java -jar karate.jar datetest.feature
). Отчет о результате прохождения теста будет отображен в консоли и также будет установлено значение кода возврата в 0 (при успешном выполнении) или код ошибки, что позволяет использовать Karate DSL при автоматическом запуске тестов в CI/CD.
Как составить баг-репорт, чтобы коллеги сказали вам спасибо? Об этом и не только мои коллеги из OTUS расскажут на бесплатном уроке, который пройдет уже 10 августа. Регистрация на урок доступна по ссылке.