Postman — Collection runner, тесты и сниппеты (Snippets), запуск тестов в CI через Newman.
В предыдущей статье уже была затронута такая функциональность Postman, как collection runner. Runner был рассмотрен там как инструмент для создания инкремента значений, но назначение этой фичи не только в этом. Основная его функция в автоматическом прогоне запросов по нажатию на одну кнопку. К запросам можно прикрутить и сами тесты с помощью сниппетов, о них я тоже расскажу в этой статье, а также разберём запуск тестов через CI с помощью Newman.
Postman collection runner.
Итак, коллекция создана и все запросы расположены как вам нужно. Теперь, чтобы проверить весь API, нужно вручную прогонять каждый запрос. Звучит неудобно. Специально для прогона всех запросов существует runner. Эта функциональность Postman запускает поочерёдно все запросы, которые есть в коллекции.
Разберём Postman collection runner на уже полюбившейся тестовой коллекции Postman echo:
- Скачиваем коллекцию с ресурса, указанного выше (представим, что добрый QA или разработчик заботливо предоставил вам эту коллекцию для API вашего проекта, которая уже заполнена, и даже тесты есть).
- Сразу запускаем на этой коллекции runner.
- В открывшемся окне runner’а нажимаем на кнопку “Run %collection name%”.
- Происходит процесс прогона всей коллекции. По окончании прогона — видим статистику по успешным/неуспешным запросам и тестам, которые были прописаны в каждом запросе.
- Нажимаем оранжевую кнопку “Run summary”, чтобы систематизировать отчёт.
В целом, мы протестировали всю коллекцию нажатием пары кнопок, а не прогоном каждого запроса по отдельности. Это очень полезно, когда на бэкенде произошла масштабная работа, и после деплоя могло что-то отвалиться. Один прогон раннером позволяет понять, что деплой что-то сломал или, наоборот, всё в порядке. Но почему же некоторые запросы отработали неверно?
На summary можно отсеять успешные запросы/тесты и посмотреть только те, которые были провалены. Для этого в левой части интерфейса нужно нажать на красный квадрат.
Развернув один из неуспешных запросов (например Hawk Auth), можно увидеть, что в запросе был прописан тест, и он провалился.
Вернёмся в основной интерфейс Postman, прогоним этот запрос отдельно и заглянем во вкладку “tests”.
После выполнения запроса стандартным способом, можно увидеть, что статус был OK 200, ответ пришёл верный (авторизация прошла успешно), но тесты выполнены лишь наполовину: один из двух. Разберёмся, что за тесты были прописаны в этом запросе.
Первый тест был направлен на то, чтобы статус ответа был OK и код 200. Здесь всё понятно, мы видим, что статус ответа “200 ОК”. А что насчёт второго, который был провален?
На самом деле, всё просто. Здесь содержится тест на проверку того, что body ответа содержит слова “status” и “pass”. По факту, body имеет другое содержание, а именно:
{
“message”: “Hawk Authentication Successful”
}
Изменим тест так, чтобы он был успешен. Берём сниппет (о сниппетах расскажу позже в этой статье), который отвечает за проверку содержания body в ответе, который был прописан, но не подходит по условиям проверки.
pm.test(“response body has json saying passed ‘status’”, function () {
pm.response.to.have.jsonBody(‘status’, ‘pass’);
});
Отредактируем его под наш сценарий:
pm.test(“response body has json saying ‘Hawk Authentication Successful’”, function () {
pm.response.to.have.jsonBody(‘message’, ‘Hawk Authentication Successful’);
});
В первой строчке указано название теста. Я его назвал: body ответа в формате json содержит “Hawk Authentication Successful”. Сама проверка идёт второй строчкой: ответ содержит строчку “message” с содержанием “Hawk Authentication Successful”.
Пробуем снова отправить этот запрос с обновленным тестом:
В итоге в процессе прогона коллекции в Postman Runner мы больше не увидим ошибку на запросе “Hawk Auth”. По аналогии можно отредактировать все тесты на все запросы и иметь мега-коллекцию с тестами и с прогоном тестов всего API в 3 клика.
Редактировать готовые тесты несложно, просто подменяя неправильные значения, которые ожидает увидеть тест на те, которые приходят (если они правильные). Но что делать, если тесты никто не прописывал до вас? Прописать их самим, конечно же! :)
Snippets
После открытия вкладки “Tests” внимание привлекает список справа.
Это те самые сниппеты, которые помогут в написании тестов, прогоняемых в раннере. Сниппеты все разные и можно выбрать те, которые обеспечат максимальное покрытие запроса тестами. Например:
- проверить статус-код ответа
- проверить наличие string строки в ответе или конкретного значения внутри JSON
- проверить время ответа
- проверить наличие определенного заголовка в ответе
- конвертировать XML ответ в JSON объект
Давайте попробуем прописать свои тесты на какой-либо запрос, используя всё ту же коллекцию Postman echo.
Покажу на примере запроса в папке “Request methods”, называемого “Get request”. Для начала нам нужно очистить все тесты, которые там были прописаны до нас.
После этого выполнить успешный запрос кнопкой “Send”.
В сниппетах нужно выбрать “Status code is 200” и автоматически подставляется схема теста. Если нужен какой-либо другой код ответа, просто правим его руками с 200 на любой другой, в зависимости от положительного сценария.
Далее нужно выбрать “Response time is less than 200ms” сниппет, чтобы проверить время ответа. Поскольку нам пришло значение в 998ms, будем считать, что валидное значение — 1000ms. Правим это в коде теста, который подставляется автоматически после нажатия на сниппет.
Последний тест, который я пропишу, будет на проверку верно пришедшего body JSON. Нужно выбрать сниппет “response body: is equal to a string”. Название у теста автоматически назначается “Body is correct”. Сделаем проверку на то, что в body пришли следующие значения:
“args”: {
“foo1”: “bar1”,
“foo2”: “bar2”
},
В итоге тест будет выглядеть следующим образом:
pm.test(“response body has json with request queries”, function () {
pm.response.to.have.jsonBody(‘args.foo1’, ‘bar1’)
.and.have.jsonBody(‘args.foo2’, ‘bar2’);
});
(Стоит обратить внимание, что перед “body” я прописал “json”, т.к. ответ приходит именно в json формате)
В итоге все 3 теста будут иметь следующий вид:
Если выполнить запрос, внизу во вкладке “Test Results” будет 3/3 успешных. Можно смело переходить к следующему запросу и прописывать ему свои тесты. А далее, через Postman Runner прогонять все свои запросы и тесты, когда это потребуется.
Newman и запуск тестов в CI.
Когда у нас в руках такая мощь, как весь API с тестами в формате Postman Collection, грех не использовать эту библиотеку при деплое кода на бэкенд, чтобы через CI все тесты прогонялись автоматически.
Newman — это cli приложение, которое позволяет запускать Postman коллекцию с консоли. Его можно легко интегрировать в ваш CI. Я расскажу, как я запускал Newman у себя на локалке, но принцип запуска на CI тот же.
Для использования Newman предварительно нужно установить Node.js. Если Node.js уже есть, то нужно убедиться, что его версия 10 или выше. Гайдов по установке много, для примера можно воспользоваться этим.
После того, как всё установлено, нужно открыть консоль и установить сам Newman с помощью команды:
npm install -g newman
Далее, нам нужно получить URL нашей коллекции. Как это делается, я уже писал, но повторю: напротив нужной коллекции в Postman нужно нажать на кнопку опций (…) и выбрать пункт “Share collection”.
После этого откроется окно шаринга, в нём нужно выбрать пункт “Get public link” и нажать на кнопку “Get public link”, после чего генерируется ссылка на выбранную коллекцию (которая будет содержать в себе все прописанные тесты).
Также можно взять сам файл коллекции, а не URL. Скачивание .JSON файла коллекции осуществляется с помощью пункта “Export” после нажатия той же кнопки опций (…), далее сохраняем файл на диск.
Newman установлен, ссылка на коллекцию или .JSON файл есть. Теперь запускаем тесты в консоли следующей командой:
newman run https://www.getpostman.com/collections/65bd30a9d3e7243f3f02
(URL нужно подставить тот, который получили при шаринге и нажатии на кнопку “Get public link”)
Для запуска newman из файла .JSON нужно использовать команду с директорией файла коллекции. Например:
newman run /Users/Alienware/Desktop/Postman Echo.postman_collection.json
Вся коллекция была протестирована одной командой. Также присутствует аналитика, которая показывает, сколько всего было запросов, сколько тестов, какие прошли, какие нет. Надстройкой в вашем CI можно прописать, чтобы этот прогон выполнялся после каждого деплоя на бекенд. Вы великолепны!
После прочтения всех моих статей и практического использования знаний, можно смело добавлять ещё одну увесистую строчку в ваше резюме.
Ну а если ещё не читали — вот ссылки:
- 1) Postman — как инструмент тестирования API
- 2) Postman — менеджмент, структурирование, импорт и экспорт коллекций
- 3) Postman — cмена окружений, предварительная настройка авторизации, установка переменных
Огромное спасибо за прочтение!
Если вам или кому-то из ваших знакомых нужно разработать качественное мобильное приложение, веб-сервис или помочь в решении бизнес-задач, смело обращайтесь к нам в Effective, мы готовы сотрудничать с вами в любом виде: как на проекте целиком, так и на аутстаф. Связаться с нами можно через почту contact@effective.band
