Введение
Предположим, в вашем проекте написан http-сервис для обмена информацией с другой информационной системой. Для бизнес-пользователей он очень важен, и вы хотите быть уверенным, что в следующем релизе он будет работать. Попробуем покрыть его тестами при помощи известного инструмента postman. Зачем все это нужно, по верхам описано в данной статье, в этой планирую показать детали и снизить порог входа. Также рекомендую прочесть вот эту статью, она точно поможет для проверки стороннего сервиса, к которому вы подключаетесь из 1С.
Поехали
Чтобы установить postman, достаточно перейти по ссылке https://www.postman.com/downloads/, нажать кнопку download и кликнуть на полученный exe файл, если, конечно, вы работаете на ОС windows.
Postman вас встретит окном регистрации, крайне рекомендую выполнить данный шаг, в качестве награды вы получите сохранение вашей работы в вашем личном профиле. Первое, что нужно сделать, на мой субъективный взгляд, – это установка темной темы.
Первый запрос
Думаю, вы справились с публикацией информационной базы на веб-сервере и собрали адресную строку по статье на ИТС, в моем примере она выглядит так «http://localhost/conf83/hs/orders-api/». Теперь пора выполнить первый запрос. Обратимся к первому методу (в простонародье endpoint), который отвечает за работоспособность нашего API под названием status, открыв новую закладку.
Можете заметить, что в типовых решениях есть метод ping, даже можете найти стандарт, но на мой субъективный взгляд, лучше использовать нейминг status и по-честному отвечать json'ом. Тут мне хотелось бы понимать, что вы знаете о протоколе http и работали с ним, если нет - то прошу в эту статью.
Коллекции, переменные
Для дальнейшего использования нашего запроса сохраним его, добавив и создав новую коллекцию запросов. Коллекция – список нескольких запросов.
Чтобы не копипастить постоянно адрес, добавим его в переменную «baseUrl». Переменные в postman выделяются двойными фигурными скобками.
Чтобы открыть список переменных, достаточно перейти к нашей коллекции. В данном окне можно изменить значение на случай смены, например, адреса или добавить новую.
Для редактирования конкретного значение используйте колонку Current value.
Параметры запроса
Перед тем как начать работать с параметрами запроса, добавим новый запрос, методом копипаста. Можно заметить, что postman не находит переменную, все верно, потому область видимости переменной – коллекция. Сохраним запрос в коллекцию, ошибка исчезнет, запрос отработает корректно.
Параметры запроса могут быть обязательными и не обязательными. В нашем API тип (он же вид) номенклатуры не обязательный параметр, но может принять 2 значения: Товар, Услуга. Ключ параметра и его значение сами будут добавляться к тексту запроса. Попробуем добавить параметр и указать несуществующий тип
Вернулся статус 400, который обозначает ошибку. В ответе можно попытаться проанализировать причину. Нет особых правил, какие параметры использовать в запросе, какие из них обязательные и какие значения могут принимать, эти тонкости стоит отражать в документации к вашему API. Но настоятельно рекомендовал бы возвращать коды ошибок 4хх при ее наличии с указанием причины ошибки в ответе. Исправим ошибку?
Обратите внимание, что ключи параметров регистрозависимые.
Еще один способ передачи необязательных параметров – передавать их параметром в адресной строке. Каждый инструмент дает немного сахара, и Postman не исключение. Предположим, необходимо предоставить расширенную информацию о конкретной номенклатуре, передав ее идентификатор. Что ж, давайте добавим новый запрос в нашу коллекцию.
Идентификатор ручки мы взяли из метода List sku. На самом деле не очень важно, что вы укажете в качестве ключа «skuid» или «sku», так как на самом деле postman отправит запрос на адрес http://localhost/conf83/hs/orders-api/sku/ee9ad060-20ef-11e7-ba56-94de806096e9, подменив ключ на его значение.
Если отправить запрос с несуществующей номенклатурой, то метод должен вернуть статус 404 и текст ошибки
POST запросы
Давайте попробуем оформить заказ на какой-либо товар. Для этого мы будем использовать post запрос к методу Order. На всякий случай напомню, что методы post в общем случае предназначены для отправки данных, в нашем случае заказа. Попробуем выполнить отправку с пустым телом запроса.
Получили ошибку 401 и текст ошибки "Отсутствует заголовок аутентификации". Дело в том, что часть ваших методов api могут быть доступны всем без авторизации, остальная - требовать ее наличие. Опять же нет жестких ограничений, все зависит от ваших требований к безопасности и процедуре регистрации клиентов в вашей системе. Так как требования у всех разные, рассмотрим самый простой способ авторизации с предварительной регистрацией через api и получением токена (token).
Регистрация клиента (без смс)
Для регистрации у нас есть метод api-clients, куда следует передать имя пользователя и электронную почту пользователя в формате json на закладке Body. В ответ получим токен, который будем использовать для остальных методов api. Используя данный токен, мы будем понимать, кто (какой пользователь) выполняет данный метод.
Итак, мы отправили запрос на регистрацию, получили успешный код (он же статус) ответа (201), в теле сообщения - токен для входа.
Немного сахара от постмана - указав тип передачи сообщения json, получите валидацию содержимого. Теперь сохраним полученный токен в новую переменную нашей коллекции.
Вернемся к нашему методу создания нового заказа, который требовал аутентификации. Обычно токен передается в заголовке запроса. Мы можем указать его на закладке Headers, а можем - на соответствующей закладке аутентификации. Тут огромный список вариантов типов, один из самых распространённых Bearer Token.
Как вы могли заметить, postman сам добавил соответствующий заголовок Authorization. Выполнив запрос, мы по-прежнему получили ошибку, но уже 400ую, значит аутентификация выполнена, осталось передать информацию для формирования нового заказа.
Метод вернул 201 статус, значит, заказ создан. В теле ответа видим идентификатор нового заказа. Помните, что в методе sku было поле, которое указывает, доступна ли номенклатура или нет?
Тестирование api
Что ж, предварительная работа выполнена, коллекция всех запросов api подготовлена. До этих пор мы вручную выполняли каждый запрос и переносили идентификаторы между методами. По сути, методы можно собрать в некий единый процесс, т.е. сначала мы удостоверяемся в наличии отклика api, получаем список номенклатур, узнаем цену и остаток каждой из них и выполняем оформление заказа с предварительной регистрацией.
Вся суть тестирования api заключается в анализе ответов каждого метода. К примеру, метод status должен вернуть код 200, а тело сообщения должно содержать поле status со значением OK. Перейдем к закладке Test и напишем первый простой тест, который пишется на javascript.
Справа есть небольшой генератор кода, а также ссылка на документацию тестов.
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
Код выше очень простой и легок в понимании. Статус ответа данного метода должен быть равен значению 200.
Для проверки сообщения добавим строку анализа json, так как api может вернуть html в случае ошибки сервиса, который не удастся распарсить, и проверим значение строкой кода.
pm.expect(pm.response.status).to.eql("OK");
Если попытаться обратиться к несуществующему адресу или сравнить поле со значением “NOT OK”, тест упадет.
Теперь можно добавить проверку статуса в каждый метод, кстати ключевое слово function является устаревшим. Методы, которые, что-то создают, как правило, возвращают код 201, а не 200.
Передача результата между методами api
У нас есть 2 связанных метода sku и sku/:skuid. В первом мы получаем общий список номенклатур, во втором - детальную информацию о номенклатуре с ее ценами и остатками. По сути сейчас нужно скопипастить идентификатор из первого запроса и перенести во второй. Как это сделать автоматически? Итак, наша задача из метода sku получить идентификатор первой доступной номенклатуры и сохранить его в переменную. Метод возвращает поле sku, в котором находится массив всех элементов, доступных и не доступных, см поле available. Чтобы найти необходимый элемент в массиве можно воспользоваться функцией filter(). Из полученного массива обратиться к первому элементу, из которого получить поле id. Все делается в 3 строки кода.
const response = pm.response.json();
const availableSkus = response.sku.filter((availableSku) => availableSku.available === true);
console.log(availableSkus[0].id);
Останется только сохранить результат поиска в переменную коллекции и обратиться к переменной в следующем методе.
pm.collectionVariables.set("skuId", availableSkus[0].id);
Отлично, но что если сервис не вернет ни одной доступной к заказу номенклатуры? Мы получим ошибку компиляции, так как обращаемся к первому элементу массива, который может быть пустым. Лучше это поправить, сохранять идентификатор только если первый элемент существует и написать скрипт, который проверяет что, хотя бы одна номенклатура найдена.
Осталось только чуть-чуть повысить вариативность нашего теста, используя переменные и рандомайзер.
Runner
Теперь все готово, чтобы проверить api в один клик. Закроем все запросы, сохранив их в коллекцию, и откроем Runner.
Все тесты прошли успешно. Получилось очень по верхам, но достаточно, чтобы погрузиться в очень интересный инструмент с огромным количеством возможностей.
Приложена доработанная каркасная конфигурация с экзамена 1С:Специалист по платформе на версии платформы 8.3.17.1851.
