Немножко про автоматизацию тестирования API

Тестирование сетевых приложений разделяется на несколько взаимосвязанных этапов и значительно зависит от корректности работы 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 августа. Регистрация на урок доступна по ссылке.