rest assured что это
Руководство по REST-уверены
Изучите основы программы REST-assured – библиотеки, которая упрощает тестирование и проверку API REST.
1. Введение
КОМПАНИЯ REST-assured была разработана для упрощения тестирования и проверки API REST и в значительной степени зависит от методов тестирования, используемых в динамических языках, таких как Ruby и Groovy.
Библиотека имеет твердую поддержку HTTP, начиная, конечно, с глаголов и стандартных операций HTTP, но и выходит далеко за рамки этих основ.
Кроме того, чтобы узнать о более продвинутых случаях использования REST-assured, ознакомьтесь с другими нашими статьями:
Теперь давайте погрузимся в с простым примером.
2. Простой пример теста
Прежде чем мы начнем, давайте гарантируем, что наши тесты имеют следующие статические импорта:
Нам нужно, чтобы тесты были простыми и имели легкий доступ к основным API.
Теперь давайте начнем с простого примера – базовой системы ставок, разоблачающих некоторые данные для игр:
Допустим, это ответ JSON от удара локально развернутых API – http://localhost:8080/events?id=390. :
Давайте теперь использовать REST-уверены, чтобы проверить некоторые интересные особенности ответа JSON:
Итак, что мы сделали здесь – мы проверили, что вызов в конечную точку /события?id-390 отвечает телом, содержащим JSON Струнные чьи leagueId из данные объект 35.
Рассмотрим более интересный пример. Допустим, вы хотели бы проверить, что шансы массив имеет записи с ценами 1.30 и 5.25 :
3. Установка, гарантированная REST
Если вашим любимым инструментом зависимости является Maven, мы добавляем следующую зависимость в пом.xml файл:
4. Анонимная проверка корня JSON
Рассмотрим массив, который состоит из примитивов, а не объектов:
Это называется анонимным корнем JSON, что означает, что он не имеет пары ключевых значений, тем не менее, он по-прежнему действителен JSON данных.
5. Поплавки и парный разряд
Когда мы начинаем использовать РЕСТ-гарантированные для тестирования наших услуг REST, мы должны понимать, что плавающие точечные числа в ответах JSON отображаются на примитивных типах плавать.
Использование поплавок тип не взаимозаменяем с двойной как и во многих сценариях java.
В качестве точки зрения зрения зрения имеется такой ответ:
предположим, что мы запускаем следующий тест на значение ck :
6. Определение метода запроса
Как правило, мы выполняем запрос, вызывая такой метод, как получить (), в соответствии с методом запроса, который мы хотим использовать.
Кроме того, мы также можем указать глагол HTTP, используя запрос () метод :
Приведенный выше пример эквивалентен использованию получить () прямо.
Поместить запрос также следует аналогичному синтаксису, и мы можем указать тело с помощью с () и тело() методика.
Поэтому, чтобы создать новую Нечетные отправив POST просьба:
Нечетные объект, отправленный в тело автоматически преобразуется в JSON. Мы также можем пройти любое Струнные что мы хотим послать в качестве нашего POST тело.
7. Конфигурация значений по умолчанию
Мы можем настроить много значений по умолчанию для тестов:
Здесь мы устанавливаем базовый URI и порт для наших запросов. Помимо этого, мы также можем настроить базовый путь, погладить корень, и аутентификации.
Примечание: мы также можем сбросить на стандартные неувереемые в REST по умолчанию с помощью:
8. Измерение времени отклика
Давайте посмотрим, как мы можем измерить время отклика с помощью время () и timeIn () методы Ответные объект :
Обратите внимание, что:
8.1. Проверка времени отклика
Мы также можем проверить время отклика – в миллисекундах – с помощью простых долго Совпадений:
Если мы хотим проверить время отклика в другой единице времени, то мы будем использовать время () матч с второй ТаймУнит параметр:
9.XML Проверка ответов
Он не только может проверить ответ JSON, он может проверить XML, а также.
Допустим, мы делаем запрос на http://localhost:8080/employees и мы получаем следующий ответ:
Мы можем проверить, что имя это Джейн как так:
Мы также можем проверить, что все значения соответствуют нашим ожидаемым значениям, приковав вместе спички тела так:
Или с помощью сокращенной версии с переменными аргументами:
10. XPath для XML
Мы также можем проверить наши ответы с помощью XPath. Рассмотрим пример ниже, который выполняет матч на имя :
XPath также принимает альтернативный способ запуска равныйВ Совпадений:
11. Подробная информация о тестировании журналов
11.1. Подробная информация о запросе журнала
Во-первых, давайте посмотрим, как войти все детали запроса с помощью журнал ().все() :
Это будет журнал что-то вроде этого:
Чтобы войти только в определенные части запроса, у нас есть журнал () метод в сочетании с парамы (), тело (), загонщики (), печенье (), метод (), путь () например, журнал. ().парамы ().
Обратите внимание, что другие библиотеки или фильтры могут изменять то, что на самом деле отправляется на сервер, поэтому это должно использоваться только для регистрации спецификации первоначального запроса.
11.2. Подробная информация о регистрации
Аналогичным образом, мы можем войти детали ответа.
В следующем примере мы регистрим только тело ответа:
11.3. Реакция журнала если условие произошло
У нас также есть возможность регистрации ответа только в том случае, если произошла ошибка или код статуса соответствует данному значению:
11.4. Если проверка не удалась
Мы также можем регистрировать как запрос, так и ответ только в том случае, если наша проверка не была смогла:
В этом примере мы хотим проверить, что код статуса 200. Только в том случае, если это не удается, запрос и ответ будут зарегистрированы.
12. Заключение
В этом учебнике мы изучили рамочную систему, гарантированную и посмотрел на его наиболее важные функции, которые мы можем использовать для тестирования наших услуг RESTful и проверки их ответов.
REST Assured: что мы узнали за пять лет использования инструмента
REST Assured — DSL для тестирования REST-сервисов, который встраивается в тесты на Java. Это решение появилось более девяти лет назад и стало популярным из-за своей простоты и удобного функционала.
В DINS мы написали с ним более 17 тысяч тестов и за пять лет использования столкнулись со множеством «подводных камней», о которых нельзя узнать сразу после импорта библиотеки в проект: статическим контекстом, путаницей в порядке применения фильтров к запросу, трудностями в структурировании теста.
Эта статья — о таких неявных особенностях REST Assured. Их нужно учитывать, если есть шанс, что количество тестов в проекте будет быстро увеличиваться — чтобы потом не пришлось переписывать.
Что тестируем
DINS участвует в разработке UCaaS-платформы. В том числе мы разрабатываем и тестируем API, который компания RingCentral использует сама и предоставляет сторонним разработчикам.
При разработке любого API важно следить, чтобы он работал корректно, но когда отдаешь его наружу, приходится проверять намного больше кейсов. Поэтому на каждый новый эндпоинт добавляются десятки и сотни тестов. Тесты написаны на Java, в качестве тестового фреймворка выбран TestNG, а для запросов к API используется REST Assured.
Когда REST Assured принесет пользу
Если вашей целью не является досконально протестировать весь API, то проще всего это сделать с REST Assured. Он хорошо подходит для проверки структуры ответов, PVD и smoke-тестов.
Так выглядит простой тест, который будет проверять, что эндпоинт отдает статус 200 OK при обращении к нему:
Реальные тесты обычно больше и сложнее. В запросы добавляются заголовки, куки, авторизация, тело запроса. И если тестируемый API не состоит из десятков уникальных ресурсов, каждый из которых требует особых параметров, вы захотите где-то хранить уже готовые шаблоны, чтобы добавлять их потом к конкретному вызову в тесте.
Для такого в REST Assured существуют:
RequestSpecification и ResponseSpecification
Эти два класса позволяют определить параметры запроса и ожидания от ответа:
Одна спецификация используется в нескольких вызовах, тестах и тестовых классах в зависимости от того, где определена — ограничения нет. Можно даже добавлять несколько спецификаций к одному запросу. Однако это — потенциальный источник проблем:
Получилось, что в вызов добавлены все заголовки, а вот URI внезапно стал localhost — хотя его добавили в первой спецификации.
Это произошло из-за того, что REST Assured по-разному справляется с переопределениями для параметров запроса (с ответом то же самое). Заголовки или фильтры добавляются в список, а потом по очереди применяются. URI может быть только один, поэтому применяется последний заданный. В последней добавленной спецификации его не задали — поэтому REST Assured переопределяет его дефолтным значением (localhost).
Если добавляете к запросу спецификацию — добавляйте одну. Совет кажется очевидным, но когда проект с тестами разрастается, возникают классы-хэлперы и базовые тестовые классы, внутри них появляются before-методы. Уследить за тем, что на самом деле происходит с вашим запросом, становится сложно, особенно если тесты пишет сразу несколько человек.
Базовая конфигурация REST Assured
Другой способ шаблонизировать запросы в REST Assured — настроить базовую конфигурацию и определить статические поля класса RestAssured:
Значения будут автоматически добавляться к запросу каждый раз. Конфигурация сочетается с аннотациями @BeforeMethod в TestNG и @BeforeEach в JUnit –– так можно быть уверенными, что каждый запущенный тест будет начинаться с одними и теми же параметрами.
Тем не менее, конфигурация станет потенциальным источником проблем, ведь она является статической.
Пример: перед каждым тестом берем тестового пользователя, получаем для него авторизационный токен, а потом добавляем его через AuthenticationScheme или авторизационный фильтр к базовой конфигурации. Пока тесты запускаются в один поток, все будет работать.
Когда тестов становится слишком много, обычное решение разделить их выполнение на несколько потоков приведет к переписыванию куска кода, чтобы токен из одного треда не попал в соседний.
Фильтры REST Assured
Фильтры изменяют как запросы перед отправкой, так и ответы перед проверкой на соответствие заданным ожиданиям. Пример применения — добавление логирования, или авторизации:
Порядок фильтров имеет значение. Эти два запроса приведут к разным логам: в первом будет указан авторизационный заголовок, во втором — нет. При этом заголовок будет добавлен в оба запроса — просто в первом случае REST Assured сначала добавит авторизацию до того, как залогировать, а во втором — наоборот.
Конечно, здесь можно запутаться и случайно выставить двум фильтрам одинаковый приоритет, например, в 999. Тогда первым к запросу будет применен тот, который был добавлен раньше.
Не только фильтры
Как сделать авторизацию через фильтры, показано выше. Но кроме этого способа в REST Assured существует и другой, через AuthenticationScheme :
Это устаревший способ. Вместо него стоит выбрать тот, который показан выше. Причины две:
Проблема с зависимостями
Документация к REST Assured указывает, что для использования Oauth1 или Oauth2 (указывая токен в качестве query-параметра) авторизации необходимо добавить в зависимости Scribe. Однако импорт последней версии вам не поможет — у вас возникнет ошибка, описанная в одной из открытых проблем. Решить ее можно только импортом старой версии библиотеки, 2.5.3. Однако в этом случае вы наткнетесь на другую проблему.
Вообще никакая другая версия Scribe не работает с Oauth2 REST Assured версии 3.0.3 и выше (и недавний выход 4.0.0 это не исправил).
Логирование не работает
Фильтры применяются к запросам в определенном порядке. А AuthenticationScheme применяется после них. А значит, будет трудно обнаружить проблему с авторизацией в тесте — она же не залогируется.
Еще о синтаксисе REST Assured
Большое количество тестов обычно значит, что они еще и сложные. А если API является основным предметом тестирования, и нужно проверить не просто поля json’a, а бизнес-логику, то с REST Assured тест превращается в простыню:
Этот тест проверяет, что, когда мы кормим Куки-монстра, мы правильно подсчитываем, сколько печенек ему дали, и указываем это в истории. Но с первого взгляда это нельзя понять — все запросы выглядят одинаково, и неясно, где заканчивается подготовка данных через API, а где посылается тестируемый запрос.
И вызывать в тесте:
Хорошо, когда такие классы-хэлперы универсальны, чтобы вызов одного метода можно было встроить в большое количество тестов — тогда их вообще можно вынести в отдельную библиотеку: вдруг потребуется в какой-то момент вызвать метод в другом проекте. Только при этом придется убрать всю проверку ответа, которую может сделать Rest Assured — все-таки в ответ на один и тот же запрос часто могут вернуться совсем разные данные.
Заключение
REST Assured — это библиотека для тестирования. Она умеет делать две вещи: посылать запросы и проверять ответы. Если мы пытаемся вынести ее из тестов и убрать всю валидацию, то она превращается в HTTP-клиент.
Если вам предстоит написать большое количество тестов и в дальнейшем их поддерживать – задумайтесь, нужен ли в них HTTP-клиент с громоздким синтаксисом, статической конфигурацией, путаницей в порядке применения фильтров и спецификаций и логированием, которое можно легко сломать? Может быть, девять лет назад REST Assured был самым удобным инструментом, но за это время появились альтернативы, — Retrofit, Feign, Unirest и т.д., — у которых нет таких особенностей.
Большинство проблем, которые описаны в статье, проявляют себя в крупных проектах. Если вам нужно быстро написать пару тестов и навсегда про них забыть, а Retrofit не нравится, REST Assured — лучший вариант.
Если вы уже пишете тесты с использованием REST Assured, не обязательно бросаться все переписывать. Если они стабильные и быстрые, это потратит больше вашего времени, чем принесет практической пользы. Если нет — REST Assured не ваша основная проблема.
Каждый день количество тестов, написанных в DINS для API RingCentral, становится все больше, и они по-прежнему используют REST Assured. Количество времени, которое придется потратить, чтобы перейти на другой HTTP-клиент хотя бы в новых тестах, слишком велико, а созданные классы-хэлперы и методы, настраивающие конфигурацию тестов, решают большинство проблем. В этом случае сохранить цельность проекта с тестами важнее, чем использовать самый красивый и модный клиент. REST Assured, несмотря на свои недостатки, выполняет свою главную работу.
Практика тестирования бэкенда на Java + Rest-Assured
В предыдущей статье я поделился своим опытом автоматизации на Robot Framework. Теперь же речь пойдет о несколько другом подходе к тестированию API для проекта на Kotlin.
Воспользовавшись свободой выбора стека технологий и опираясь на желание попробовать «в бою» что-то новое, я обратился к Rest-Assured. Не без некоторых сложностей мы с коллегами запустили тесты, а по итогам освоения подхода записали его в список ключевых для подобного рода задач.
(изображение используется на правах пародии)
Началось все с того, что поступил запрос на автоматизацию тестирования API на одном из новых проектов в сегменте Ad-tech. Мы делали Campaign Manager, DMP и несколько интеграций со сторонними системами. А перед тестерами стояла предельно простая задача: автоматизировать смоук-тестирование для дальнейшей интеграции в CI и постоянного мониторинга состояния данного API, так как на него завязываются сторонние системы и корректность работы критична. Проверка бизнес-логики в данном случае не требовалась, поскольку тестируемый сервис по сути является прокси-интерфейсом.
Почему Rest-Assured?
С точки зрения автоматизации тестирования мы успели поработать в самых разных областях — UI, web, mobile, desktop, бэкенд, REST API, SOAP. Прошлый проект дал нам довольно большой опыт на Robot Framework, поэтому логичнее всего было бы использовать именно его. Большинство в команде тестирования с ним знакомы, и если потребуется срочная замена специалиста, сделано это будет быстро и фактически безболезненно. Но было принято иное решение.
Во-первых, сам проект был написан на Kotlin и собирался с помощью Gradle. При этом на стадии проектирования автотесты в отдельный проект решили не выделять. Как было отмечено в комментариях к предыдущей статье, склеить Java (Kotlin) и Robot Framework — большая боль, поэтому не было никакого смысла обращаться к RF. Плюс, оглядываясь на работу с роботом, мне было интересно попробовать иной подход. Тем более что на данном проекте мы могли самостоятельно выбирать стек технологий — бизнес не ставил своих условий.
В поисках идей я обратился к нашей команде разработки, а также коллегам из тестирования, и CTO посоветовал присмотреться к Rest-Assured (rest-assured.io). После того, как я почитал документацию и примеры тестов в открытых источниках, подход, предлагаемый Rest-Assured, показался мне очень привлекательным. Он подразумевает прием ответа от бэкенда в виде JSON, который мы десериализуем в старые добрые объекты Java.
Дальше с этой структурой можно работать как с обычным объектом. В итоге мы имеем совершенно нормальный объектно-ориентированный подход для валидации соответствия ответа API описанной структуре объекта. В качестве бонуса получаем быстрый failproof-тест структуры ответа — если объект, полученный десериализацией ответа API, будет отличаться количеством полей или их названиями, тесты упадут еще до проверки данных с ошибкой десериализации. Так мы поймем, надо нам чинить бэкенд или актуализировать тесты в соответствии с новыми требованиями к API. В нашем случае это было важно, поскольку, как я упоминал выше, на API завязано много сторонних подсистем.
Для точности отмечу, что приблизительно тот же failproof-тест можно было бы получить на RF, но немного другим путем. Однако рассказ сегодня не об этом. Лично мне был удобнее и понятнее заход со стороны Rest-Assured с сущностью, у которой есть определенные поля и методы.
Проба пера
Прежде чем начать использовать стек на реальном проекте, я решил опробовать его на небольшом CRUD-сервисе. Чтобы сразу не практиковать собственные ошибки, решил поискать best practises по данному стеку и достаточно быстро нашел статью Филиппа Хауера, где он отразил свой опыт автоматизации на Rest-Assured. После изучения статьи написать рабочую версию тестов моего сервиса не составило труда. Они получились простые, легко читаемые и понятные.
В бой!
Проект стартовал, и когда первые структуры ответов были описаны, началась подготовка тестовой документации и написание автотестов. Для понимания общей картины приведу полный стек автотестов:
Это позволило буквально на лету создавать необходимые данные и передавать их в параметрах теста.
Rest-Assured позволяет десериализовать ответ в требуемый класс. Полученный ответ раскладывается в заранее известную структуру с помощью Jackson. Классы для десериализации выглядят максимально просто — описываются все ожидаемые поля с их типами.
Дальше продолжается простая работа с объектами и ассертации конкретных полей и их значений.
Самое сложное и неочевидное, с чем мне довелось столкнуться в данным подходе, это невозможность передать в Rest-Assured в качестве одного из параметров null (результат — падение в NullPointerException). Судя по всему, это известная проблема, но исправлять ситуацию разработчик не собирается, рекомендуя либо отправлять поле пустым, либо не отправлять его вовсе. С этой проблемой мы столкнулись уже на том этапе, когда основа проекта была готова и оставалось только дописать тестовые классы. Поэтому просто немного подкорректировали свой код.
В целом подход мне понравился. Любопытно, что через некоторое время он начал применяться и на проекте другого заказчика (правда, не с нашей подачи). А собранный стек для автоматизации тестирования API (JUnit + AssertJ + Rest-Assured) мы вынесли в категорию ключевых для проектов на Java/Kotlin. В Python его тянуть будет нелогично, поскольку лучше, чтобы компетенции разработки и тестирования пересекались.
Также стоит заметить, что одно из преимуществ этого решения заключается в его масштабируемости и адаптируемости под сложную логику. А значит, оно наилучшим образом подходит для серьезных проектов, где действительно есть смысл в описании больших объектов, чистом коде и блочной архитектуре, когда есть отдельные куски, отвечающие за подготовку, передачу и получение данных в читаемом виде, а также последующую проверку данных на соответствие каким-то условиям. В маленькие проекты все это тянуть бессмысленно.
Итоги
Примерно за месяц нам удалось автоматизировать порядка 250 тестов и обеспечить требуемый уровень покрытия. Конечно же, после окончания процесса автоматизации для всех желающих была проведена внутренняя презентация, чтобы сотрудники имели представление о проделанной работе и могли перенять полученный на данном проекте опыт.