1. Введение
Чтобы тщательно протестировать веб-API, нам нужен какой-то веб-клиент для доступа к конечным точкам API. Postman — это автономный инструмент, который использует веб-API, отправляя HTTP-запросы извне службы .
При использовании Postman нам не нужно писать какой-либо код инфраструктуры HTTP-клиента только для тестирования. Вместо этого мы создаем наборы тестов, называемые коллекциями, и позволяем Postman взаимодействовать с нашим API.
В этом руководстве мы увидим, как создать коллекцию Postman, которая может тестировать REST API.
2. Настройка
Прежде чем мы начнем работу с нашей коллекцией, нам нужно настроить среду.
2.1. Установка почтальона
Postman доступен для Linux, Mac и Windows. Инструмент можно загрузить и установить с веб- сайта Postman .
После закрытия заставки мы можем увидеть пользовательский интерфейс:
2.2. Запуск сервера
Postman нуждается в живом HTTP-сервере для обработки своих запросов . В этом руководстве мы будем использовать предыдущий проект ForEach, spring-boot-rest, который доступен на GitHub .
Как можно догадаться из названия, spring-boot-rest — это приложение Spring Boot. Мы создаем приложение с целью установки Maven . После сборки мы запускаем сервер с пользовательской целью Maven spring-boot:run .
Чтобы убедиться, что сервер работает, мы можем нажать этот URL-адрес в нашем браузере:
http://localhost:8082/spring-boot-rest/auth/foos
Этот сервис использует базу данных в памяти. Все записи очищаются при остановке сервера.
3. Создание коллекции почтальона
Коллекция в Postman — это серия HTTP-запросов. Почтальон сохраняет все аспекты запросов, включая заголовки и тела сообщений. Поэтому мы можем запускать запросы последовательно как полуавтоматические тесты .
Начнем с создания новой коллекции. Мы можем щелкнуть стрелку раскрывающегося списка на кнопке « Создать » и выбрать « Коллекция» :
Когда появится диалоговое окно CREATE A NEW COLLECTION , мы можем назвать нашу коллекцию « foo API test ». Наконец, мы нажимаем кнопку « Создать » , чтобы наша новая коллекция появилась в списке слева:
Как только наша коллекция создана, мы можем навести на нее курсор, чтобы открыть две кнопки меню. Кнопка со стрелкой открывает выпадающую правую панель, которая обеспечивает доступ к средству запуска коллекции . И наоборот, кнопка с многоточием открывает раскрывающееся меню, содержащее ряд операций над коллекцией.
4. Добавление POST-запроса
4.1. Создание нового запроса
Теперь, когда у нас есть пустая коллекция, давайте добавим запрос, который обращается к нашему API. В частности, давайте отправим сообщение POST на URI /auth/foos. Для этого мы открываем меню с многоточием в нашей коллекции и выбираем « Добавить запрос».
Когда появится диалоговое окно SAVE REQUEST , давайте дадим описательное имя, например « добавить foo». Затем нажмите кнопку Сохранить в foo API test .
Как только запрос создан, мы видим, что наша коллекция указывает на один запрос . Однако, если наша коллекция не была расширена, то мы еще не можем видеть запрос. В этом случае мы можем щелкнуть коллекцию, чтобы развернуть ее.
Теперь мы должны увидеть новый запрос, указанный в нашей коллекции. Мы можем заметить, что новый запрос по умолчанию представляет собой HTTP GET, а это не то, что нам нужно. Мы исправим это в следующем разделе:
4.2. Редактирование запроса
Чтобы отредактировать запрос, щелкнем по нему, тем самым загрузив его во вкладку редактора запросов:
Хотя редактор запросов имеет множество опций, нам пока нужны только некоторые из них.
Во-первых, давайте воспользуемся раскрывающимся списком, чтобы изменить метод с GET на POST.
Во-вторых, нам нужен URL. Справа от раскрывающегося списка методов находится текстовое поле для URL-адреса запроса. Итак, давайте введем это сейчас:
http://localhost:8082/spring-boot-rest/auth/foos
Последним шагом является предоставление тела сообщения. Под URL-адресом находится ряд заголовков вкладок. Мы щелкнем заголовок вкладки « Тело », чтобы перейти к редактору тела.
На вкладке « Тело », прямо над текстовой областью, есть ряд переключателей и раскрывающийся список. Они управляют форматированием и типом содержимого запроса.
Наш сервис принимает данные JSON, поэтому мы выбираем необработанный переключатель . В раскрывающемся списке справа мы применяем тип контента JSON (application/json) .
После того, как кодировка и тип контента были установлены, мы добавляем наш контент JSON в текстовую область:
{
"name": "Transformers"
}
Наконец, давайте обязательно сохраним наши изменения, нажав Ctrl-S или нажав кнопку « Сохранить ». Кнопка « Сохранить » расположена справа от кнопки « Отправить ». После сохранения мы видим, что запрос был обновлен до POST в списке слева:
5. Запуск запроса
5.1. Выполнение одного запроса
Чтобы выполнить один запрос, мы просто нажимаем кнопку « Отправить » справа от URL-адреса. Как только мы нажмем « Отправить», под панелью запроса откроется панель ответов. Возможно, потребуется прокрутить вниз, чтобы увидеть его:
Давайте рассмотрим наши результаты. В частности, в строке заголовка мы видим, что наш запрос выполнен успешно со статусом 201 Created . Кроме того, тело ответа показывает, что наша запись Transformers получила идентификатор 1.
5.2. Использование бегуна коллекций
В отличие от кнопки « Отправить », средство запуска коллекции может выполнить всю коллекцию целиком . Чтобы запустить средство запуска коллекции, мы наводим курсор на нашу тестовую коллекцию foo API и нажимаем стрелку вправо. На правой панели мы видим кнопку « Выполнить» , поэтому давайте нажмем ее:
Когда мы нажимаем кнопку « Выполнить », бегун коллекции открывается в новом окне. Поскольку мы запустили его из нашей коллекции, раннер уже инициализирован для нашей коллекции:
Средство запуска коллекции предлагает параметры, влияющие на тестовый запуск, но в этом упражнении они нам не понадобятся. Давайте перейдем непосредственно к кнопке Run foo API test внизу и нажмем ее.
Когда мы запускаем сбор, представление меняется на Run Results . В этом представлении мы видим список тестов, которые отмечены зеленым цветом в случае успеха и красным в случае неудачи.
Несмотря на то, что наш запрос был отправлен, бегун указывает, что ноль тестов пройден и ноль тестов не пройден. Это потому, что мы еще не добавили тесты в наш запрос:
6. Тестирование ответа
6.1. Добавление тестов в запрос
Чтобы создать тест, вернемся к панели редактирования запроса, где мы построили наш метод POST. Мы нажимаем вкладку « Тесты », которая находится под URL-адресом. Когда мы это сделаем, появится панель Tests:
В панели Tests пишем JavaScript, который будет выполняться при получении ответа от сервера.
Postman предлагает встроенные переменные, обеспечивающие доступ к запросу и ответу . Кроме того, с помощью синтаксиса require() можно импортировать ряд библиотек JavaScript .
В этом руководстве слишком много функций сценариев. Однако официальная документация Postman — отличный ресурс по этой теме.
Продолжим, добавив в наш запрос три теста:
pm.test("success status", () => pm.response.to.be.success );
pm.test("name is correct", () =>
pm.expect(pm.response.json().name).to.equal("Transformers"));
pm.test("id was assigned", () =>
pm.expect(pm.response.json().id).to.be.not.null );
Как мы видим, эти тесты используют глобальный модуль pm , предоставленный Postman . В частности, в тестах используются pm.test(), pm.expect() и pm.response .
Функция pm.test() принимает метку и функцию утверждения , например, expect() . Мы используем pm.expect() для утверждения условий содержимого ответа JSON.
Объект pm.response обеспечивает доступ к различным свойствам и операциям над ответом, возвращенным с сервера. Доступные свойства включают, среди прочего, статус ответа и содержимое JSON.
Как всегда, сохраняем наши изменения с помощью Ctrl-S или кнопки Сохранить .
6.2. Запуск тестов
Теперь, когда у нас есть тесты, давайте снова запустим запрос. При нажатии на кнопку « Отправить » результаты отображаются на вкладке « Результаты теста » панели ответов:
Точно так же бегун коллекции теперь отображает результаты наших тестов. В частности, сводка в левом верхнем углу показывает обновленные итоговые значения успешно пройденных и не пройденных экзаменов. Под сводкой находится список, в котором показан каждый тест с его статусом:
6.3. Просмотр консоли почтальона
Postman Console — полезный инструмент для создания и отладки скриптов. Мы можем найти консоль в меню « Вид » с названием пункта « Показать консоль почтальона» . При запуске консоль открывается в новом окне.
Пока консоль открыта, она записывает все HTTP-запросы и ответы . Кроме того, когда скрипты используют console.log(), Postman Console отображает следующие сообщения:
7. Создание последовательности запросов
До сих пор мы сосредоточились на одном HTTP-запросе. Теперь давайте посмотрим, что мы можем сделать с несколькими запросами. Соединяя вместе серию запросов, мы можем смоделировать и протестировать рабочий процесс клиент-сервер .
В этом разделе давайте применим полученные знания для создания последовательности запросов. В частности, мы добавим еще три запроса для выполнения после уже созданного запроса POST. Это будет GET, DELETE и, наконец, еще один GET.
7.1. Захват значений ответов в переменных
Прежде чем мы создадим наши новые запросы, давайте внесем изменения в наш существующий запрос POST. Поскольку мы не знаем, какой идентификатор сервер назначит каждому экземпляру foo , мы можем использовать переменную для захвата идентификатора, возвращаемого сервером.
Чтобы зафиксировать этот идентификатор, мы добавим еще одну строку в конец тестового сценария POST-запроса:
pm.variables.set("id", pm.response.json().id);
Функция pm.variables.set() принимает значение и присваивает его временной переменной . В этом случае мы создаем переменную id для хранения значения id нашего объекта. После установки мы можем получить доступ к этой переменной в последующих запросах.
7.2. Добавление GET-запроса
Теперь, используя методы из предыдущих разделов, давайте добавим запрос GET после запроса POST.
С помощью этого запроса GET мы получим тот же экземпляр foo , который был создан запросом POST . Назовем этот GET-запрос как « get a foo ».
URL запроса GET:
http://localhost:8082/spring-boot-rest/auth/foos/{{id}}
В этом URL-адресе мы ссылаемся на переменную id , которую мы ранее установили во время запроса POST. Таким образом, запрос GET должен получить тот же экземпляр, который был создан POST.
Переменные, когда они появляются вне скриптов, указываются с использованием синтаксиса с двойной фигурной скобкой {{id}} .
Поскольку тела для GET-запроса нет, перейдем непосредственно к вкладке Tests . Поскольку тесты похожи, мы можем скопировать тесты из POST-запроса, а затем внести несколько изменений.
Во- первых, нам не нужно снова устанавливать переменную id , поэтому не будем копировать эту строку.
Во-вторых, мы знаем, какой идентификатор ожидать на этот раз, поэтому давайте проверим этот идентификатор. Для этого мы можем использовать переменную id :
pm.test("success status", () => pm.response.to.be.success );
pm.test("name is correct", () =>
pm.expect(pm.response.json().name).to.equal("Transformers"));
pm.test("id is correct", () =>
pm.expect(pm.response.json().id).to.equal(pm.variables.get("id")) );
Поскольку синтаксис с двойными скобками недопустим в JavaScript, мы используем функцию pm.variables.get() для доступа к переменной id .
Наконец, давайте сохраним изменения, как мы делали это раньше.
7.3. Добавление запроса на удаление
Далее мы добавим запрос DELETE, который удалит объект foo с сервера.
Мы продолжим, добавив новый запрос после GET и установив его метод на DELETE. Мы можем назвать этот запрос « удалить foo ».
URL-адрес удаления идентичен URL-адресу GET:
http://localhost:8082/spring-boot-rest/auth/foos/{{id}}
У ответа не будет тела для тестирования, но мы можем протестировать код ответа . Поэтому запрос DELETE будет иметь только один тест:
pm.test("success status", () => pm.response.to.be.success );
7.4. Проверка УДАЛЕНИЯ
Наконец, давайте добавим еще одну копию запроса GET, чтобы убедиться, что DELETE действительно работает. На этот раз давайте продублируем наш первый запрос GET вместо того, чтобы создавать запрос с нуля.
Чтобы продублировать запрос, щелкните его правой кнопкой мыши, чтобы отобразить раскрывающееся меню. Затем мы выбираем Дублировать .
К имени запроса-дубликата будет добавлено слово « Копировать ». Давайте переименуем его в « проверить удаление », чтобы избежать путаницы. Параметр « Переименовать » доступен, если щелкнуть запрос правой кнопкой мыши.
По умолчанию дубликат запроса появляется сразу после исходного запроса. В результате нам нужно будет перетащить его ниже запроса DELETE.
Последним шагом является изменение тестов. Однако, прежде чем мы это сделаем, давайте воспользуемся возможностью увидеть неудавшийся тест.
Мы скопировали запрос GET и переместили его после DELETE, но еще не обновили тесты. Поскольку запрос DELETE должен был удалить объект, тесты должны завершиться неудачно.
Давайте обязательно сохраним все наши запросы, а затем нажмем « Повторить попытку » в средстве запуска коллекции. Как и ожидалось, наши тесты провалились:
Теперь, когда наш краткий экскурс завершен, давайте исправим тесты.
Просмотрев неудачные тесты, мы видим, что сервер отвечает статусом 500. Поэтому мы изменим статус в нашем тесте.
Кроме того, просмотрев ошибочный ответ в Postman Console , мы узнаем, что ответ включает в себя свойство причины . Кроме того, свойство причины содержит строку « Нет значения ». Мы также можем проверить это:
pm.test("status is 500", () => pm.response.to.have.status(500) );
pm.test("no value present", () =>
pm.expect(pm.response.json().cause).to.equal("No value present"));
7.5. Запуск полной коллекции
Теперь, когда мы добавили все запросы, давайте запустим полную коллекцию в средстве запуска коллекции:
Если все прошло по плану, у нас должно быть девять успешных тестов.
8. Экспорт и импорт коллекции
Хотя Postman хранит наши коллекции в частном локальном месте, мы можем захотеть поделиться этой коллекцией . Для этого мы экспортируем коллекцию в файл JSON .
Команда « Экспорт » доступна в меню с многоточием коллекции. Когда будет предложено указать версию файла JSON, давайте выберем последнюю рекомендуемую версию.
После того, как мы выберем версию файла, Postman предложит указать имя файла и местоположение для экспортируемой коллекции. Например, мы можем выбрать папку в нашем проекте GitHub.
Чтобы импортировать ранее экспортированную коллекцию, мы используем кнопку Импорт . Мы можем найти его на панели инструментов главного окна Postman. Когда Postman запрашивает расположение файла, мы можем перейти к файлу JSON, который хотим импортировать.
Стоит отметить, что Postman не отслеживает экспортированные файлы. В результате Postman не показывает внешние изменения, пока мы не импортируем коллекцию повторно.
9. Заключение
В этой статье мы использовали Postman для создания полуавтоматических тестов для REST API. Хотя эта статья служит введением в основные функции Postman, мы лишь коснулись его возможностей. Онлайн - документация Postman — ценный ресурс для более глубокого изучения.
Коллекция, созданная в этом руководстве, доступна на GitHub .