Автоматизация тестирования API, или Почему я решил выбрать Postman
Буквально несколько недель назад я принял волевое решение написать API тесты для нашей доски администратора новостного портала. Для решения этой задачи существует масса инструментов и способов, реализованных на различных языках.
Но для начала пара слов о себе. На данный момент я занимаю должность Automation QA в компании Genesis Media. Мы разрабатываем новостные сайты и редакционные системы для 4 стран Африки, а также Филиппин и Казахстана. И вот, в перерыве между поточными задачами, я решил, что не так уж и плохо автоматизировать наш API. Учитывая тот факт, что до меня этого никто не делал и придется все начинать с чистого листа, у меня были развязаны руки.
Какие варианты я рассматривал
В голову мне пришло три наиболее простых решения. Первое — втоматизировать все в тестовом фреймворке для Selenium с использованием Java (я же автоматизатор все таки ;)). Второе - это использовать новомодный Cypress. Или третье — все-таки использовать узконаправленный инструмент по типу Postman или SoupUI.
Первый вариант мне нравился меньше всего по причине сложности внедрения. На данный момент все настроено таким образом, что запуск требует целой кучи параметров на CI или локально. К тому же совмещать UI тесты (end-to-end) с API (integration) — не самая лучшая из моих идей. Ну и не буду лукавить со своими читателями — я давно уже не тестировал API с использованием Java и попросту не мог вспомнить всех подводных камней или хотя бы библиотек.
В пользу Cypress говорило то, что я вот только начал его использовать и держал руку на пульсе. Да и к тому же с его использованием уже была написана часть UI-тестов для этой админки. А кто использовал этот инструмент - знает, как сильно в нем рекомендуют использовать API приложения для всего, что не является целью тестирования в конкретном тесте. Следовательно, у меня уже была часть готовых API запросов. Надо признать, что Cypress сделал все, чтобы работа с запросами не доставляла вам лишней головной боли.
Третий вариант выглядел наиболее простым и чего уж там — более желанным. С Postman, вероятно, работали все, кто хоть как-то связан с веб-разработкой, и в лишних представлениях он не нуждается. Я был не исключением, но то, чего мне ни разу не удавалось, так это не просто протестировать конкретные endpoints, но и написать тесты на его основе.
Для аргументированного решения в выборе инструмента требуется что-то немного большее, чем просто желание (глубокий вздох разочарования). Для сравнения я решил написать пару простых запросов, логин и создание статьи, в Cypress и Postman c одинаковыми проверками. Это могло дать возможность оценить сложность в написании запросов, добавлении тестов к ним и в результате понять, какой из вариантов будет удобнее поддерживать в дальнейшем. Ну и не стоит упускать из виду то, что я смогу запустить эти самые тесты и банально посмотреть, что выполняется быстрее.
Cypress
Я начал с того, что было уже готово - запросов в Cypress. Оставалось лишь убрать лишнее из кода и добавить простую проверку статуса. Итак, вот что у меня получилось для запроса регистрации и создания задачи:
Two basic API tests in Cypress
На скриншоте выше мы можем наблюдать запрос на логин и создание задачи с минимальным набором необходимых полей (названия в json схеме такие странные из-за NDA и отсутствия фантазии). После каждого запроса мы сравниваем полученный статус код с ожидаемым. Все довольно просто даже для меня - человека, не так давно начавшего свое знакомство с JavaScript. Cypress позволяет выносить общие переменные в файл cypress.json, что делает поддержку и параметризацию тестов весьма удобной. Но что же насчет скорости выполнения?
Test results in Cypress runner
На этом скриншоте вы можете увидеть Cypress runner и время, которое ушло на выполнение двух тестов - 1.87 секунды. Не такой уж и плохой результат. Но загвоздка кроется в том, что вся инфраструктура уже поднята. Если же запустить тесты из консоли, так как они и должны запускаться в CI/CD, то только на запуск самого Cypress уходит более десяти секунд. А это уже не так приятно. И пускай у нас будет несколько больше запросов, чем сейчас, но поднимать столь немалый клиент для такой простой задачи не кажется уже столь целесообразным.
Итого, мы имеем следующие плюсы Cypress:
- Простой синтаксис при написании тестов, в котором сможет за несколько дней разобраться даже новичок.
- Готовая инфраструктура с возможностью простого параметризированного запуска.
- Наличие интерактивного ранера, где можно посмотреть все ошибки прямо в консоли.
А что же из минусов:
- Очень долгий запуск.
- Необходимость писать код запросов (пусть он и не сложный).
Не так уж и много.
Postman
Теперь давайте посмотрим, как пойдет процесс с Postman. И вот вам сразу же скриншот запроса:
Request view in Postman
Здесь все достаточно банально, в особенности для тех, кто уже использовал Postman в целях тестирования API. Просто записываем все параметры и их значения в таблицу, добавляем к ним описания по необходимости. Выносим url в переменную окружения и с ее помощью прописываем endpoint. А во вкладке «Tests» выбираем сниппет для проверки статуса ответа. Единственное, с чем могут быть проблемы у начинающих, — это как передать токен из ответа логина в следующие запросы. Но это решается снова же через запись переменной в окружение. А код для этого можно взять в сниппете с говорящим названием «Set environment variable».
Окей, запускаю тесты в качестве коллекции из самого Postman и получаю следующую картину:
API test run in Postman runner
Результат — несколько меньше двух секунд на два запроса. Примерно тот же результат (на самом деле он должен был быть лучше, но интернет в новом офисе на момент написания статьи не оставил мне шансов). Но вот что мы увидим, если запустим все это из консоли?
Для решения этой задачи существует npm пакет Newman. Что ж, устанавливаем, читаем минимальную документацию и запускаем. Для этого экспортируем нашу коллекцию с запросами и тестами в них, а также не забываем экспортировать окружение, как обычное, так и глобальное, если его используем. Команда для запуска проста:
newman run имя_файла_коллекции -e имя_файла_окружения -g имя_файла_глобального_окружения
Newman run results in CLI
В результате видим идентичные результаты для отдельных запусков, но разница в том, что для старта потребовалось меньше секунды.
И после давайте быстро поговорим о плюсах и минусах (а то мне еще выводы писать, а вы и так уже поди устали все это читать).
Плюсы:
- Инструмент, с которым знакомы многие, и он крайне прост в обращении.
- Запросы пишутся быстро, и для этого не требуется никакого кода, а следовательно ими смогут воспользоваться все без исключения.
- Крайне быстрый старт тестов.
- Встроенная возможность шеринга коллекций внутри рабочей команды для платных аккаунтов.
- Генерация документации по созданным запросам и сохраненным ответам.
Минусы:
- При написании параметров запроса в форме form-data по-прежнему встречаются досадные неприятности, вроде невозможности передачи булевого значения. Они просто приводятся к строке, хотя числовые значения работают нормально.
- Примерно такая же проблема со вложенными параметрами.
Оба минуса с легкостью можно обойти, если использовать raw форму записи, но все же неприятно. А вот плюсы выглядят куда более впечатляюще.
Что же мы имеем в сухом остатке
Написание запросов в Postman проходит проще, быстрее и выглядит читабельнее. Что касается выполнения самих запросов — то тут, скорее всего, разница не существенна. Но вот что точно можно сказать, так это то, что на запуск тестов с использованием Newman не нужно дополнительное время, как в случае с Cypress.
К примеру, на данный момент наша коллекция включает в себя 60 запросов и более 100 проверок, но на их выполнение локально уходит в среднем 15 секунд. На удаленном сервере же эта цифра еще меньше и порой достигает 9 секунд, что сопоставимо со временем запуска одного Cypress.
Также просто не могу не отметить восхитительный функционал по генерации документации. Это необходимо, если ваш API все еще не имеет ничего подобного. В ней вы можете описать весь API в целом, дать примеры запросов, ответов и описание отдельным параметрам. Для всего этого можно выбрать один из нескольких предложенных языков. Все это счастье можно разместить как публично, так и приватно.
После проведенного исследования я остановил свой выбор на Postman, так как нам необходимо будет запускать эти тесты достаточно часто, и время будет весьма критичным. К тому же возможность сгенерировать документацию сыграла не последнюю роль, так как, по сути, детального описания, да еще и с примерами в едином месте у нас до сих пор не существовало.
Выводы
В этой статье я хотел передать свой опыт в выборе инструмента, но не в коей мере не настаиваю на том, что он единственно правильный. Ваш выбор может зависеть от ваших задач, потребностей и ограничений и может отличаться от текущего. В следующий раз я расскажу более подробно о самом тестировании в Postman и в частности о такой библиотеке, как tiny-json-validator, которая уже входит в набор подключенных библиотек Postman и позволяет проверять схему ответа и типы данных в нем. На этом желаю вам легких и правильных решений :)
