Тестируем REST API руками почтальона

Бла-бла-бла, информационные сети становятся все сложнее и сложнее, окутывая и людей, и приложения. Особенно приложения. Особенно приложения, которыми пользуются люди. Имея постоянно расширяющуюся и развивающуюся популяцию программных продуктов, рано или поздно пришлось бы задуматься о балансе между изоляцией приложения и его взаимодействием с другими приложениями. Большинство людей часто задумываться не любят, поэтому для них и для нас волшебниками из мира программирования была выдумана такая штука, как интерфейс программирования приложений - API (application programming interface).

API - это набор программных средств (например, функций и/или процедур) приложения, позволяющий получить доступ к этому самому приложению извне.

Ранее у нас тут появлялся обзор утилиты Hast St., созданной для упрощения проверки http-запросов. Автор в обзоре зачем-то назвал случай, когда нужно переходить к автоматизированному тестированию, противным, и оставил намек на продолжение. В этом обзоре попробуем посмотреть на эту самую "другую историю".

Postman (https://www.getpostman.com/) - это расширение для Google Chrome для проверки http-запросов. Да, как и Hast St., но Postman  имеет более богатый набор возможностей. Конструктор запросов в Postman во многом напоминает Hast St. - но тут трудно выдумать что-то оригинальное. Вводим url, выбираем тип запроса, добавляем параметры для url, хедеры или другие параметры, можем отдельно добавить параметры аутентификации (Basic Auth, Digest Auth, OAuth 1). Ничего сложного, а?

Дальше можно запустить запрос, получить результат (вместе с временем выполнения и статусом запроса) и выбрать разные варианты отображения результата (тип результата, форматирование результата). Созданный запрос можно сохранить для повторных использований в будущем. Сохраненные запросы можно объединять в коллекции и под-коллекции - эта возможность позволяет не только структуировать хранение запросов, но и запускать запросы из одной коллекции цепочкой, один-за-одним при помощи Collection Runner.

Примерно так выглядит результат запуска Collection Runner.

Так же есть возможность настройки запросов для разных окружений - большой плюс для проектов, имеющих локальные версии для тестирования, стейджинг, продакшн (или как мы еще называем такие проекты - нормальные проекты). 

Но самое интересное - это наличие конструктора тестов для запросов.
Самое интересное - редко бывает бесплатным. Создатели Postman предлагают проапгрейдить ваш аккаунт - после приобретения Jetpacks они обещают резкое ускорение и возможность создавать тесты внутри Postman. Я не успел попользоваться бесплатной версией... Как-то так вышло... Поэтому не могу сказать какие реальные преимущества дает купленный за 9,99$ Jetpacks. Единственное, что я могу сказать с уверенностью - я могу добавлять в Postman тесты для запросов.

Справа от тестового поля ввода вы можете увидеть серую панель со сниппетами, содержащую наиболее частые и полезные фрагменты кода, которые пригодятся при создании тестов (установка глобальной или локальной переменной, различные проверки).

Примерно так выглядят результаты тестов - успешный и неуспешный тесты.

Postman - зарекомендовал себя отличным средством подмоги в повседневной рутине API-тестирования. Он избавляет вас от кучи текстовых файлов с сохраненными запросами, избавляет от скучных и неказистых консольных запросов. Он позволяет добавлять тесты, круто же?

Однако, при использовании Postman на "живом" сервере непременно возникнет трудность в работе с данными. В основе автоматизированного тестирования лежит крепкий фундамент статичности исходных данных в тестовом окружении. Исходные данные должны быть всегда одинаковыми, вне зависимости от ранее запущенных тестов или порядка их запуска - иначе ваши предыдущие попытки создания, редактирования или удаления данных непременно повлияют на какие-либо тесты. Одним из выходов может быть запуск запросов группой (коллекцией), которая объединит весь жизненный цикл затронутых там данных - то, что в начале было создано (и проверено), в процессе было отредактировано (и проверено), то в конце должно быть уничтожено, бесследно. И проверено, конечно.

Возможно, пригодится эта заметка - How to Model and Test CRUD Functionality