rest assured что такое
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, несмотря на свои недостатки, выполняет свою главную работу.
Тестирование RESTful API при помощи Serenity и REST Assured на Kotlin
В этой заметке попробуем разобраться с тем, как на языке Kotlin написать тесты для проверки RESTful API приложения. В интернете полно статей про то, как писать подобные тесты на Java и Serenity, мы же воспользуемся Kotlin.
Какие технологии и библиотеки будем использовать:
Что такое Serenity BDD?
Краткий список возможностей:
Что такое Rest Assured?
Rest Assured — это Java-библиотека для тестирования RESTful API. Код, написанный с помощью этой библиотеки, имеет простой и понятный синтаксис. В тесте можно выполнить запрос к API буквально в одну строчку кода и при помощи DSL синтаксиса проверять полученный результат.
Подготовка
В оригинальной статье в качестве сборщика проекта используется maven, мы же воспользуемся Gradle. (https://gradle.org/maven-vs-gradle/)
Перед тем как приступить к написанию тестов, необходимо:
Настройка проекта в IDE
Создаем новый проект (Create new project), выбираем Gradle — Kotlin (Java):
Заполняем необходимые поля:
Указываем путь к gradle. У меня в MacOS он установлен через homebrew и Idea не находит его автоматически, поэтому я указываю путь руками: /usr/local/Cellar/gradle/4.2.1/libexec:
В итоге получаем пустой проект, с настроенным файлом конфигурации build.gradle, в котором все, что необходимо для написания кода на Kotlin, уже подключено.
Настройка зависимостей
Нам необходимо подключить следующие библиотеки:
Вносим изменения в build.gradle. Жирным шрифтом отмечены сделанные изменения относительно той версии, которая получилась после создания проекта.
Вот и вся настройка. Перейдем к написанию тестов.
Первый тест
Для написания тестов нам необходим какой-либо веб-сайт, работающий по RESTful API. Воспользуемся http://www.groupkt.com/, который предоставляет сервисы, с помощью которых, например, можно выполнить поиск страны по коду ISO при помощи метода API /country/get/iso2code/
Ниже приведён ответ сервера в формате JSON:
В папке serenity-rest-assured-automation/src/test/kotlin/tests/ создаем файл GroupktAPITest.kt и добавляем в него следующий текст:
Тест делает запрос на адрес http://services.groupkt.com/country/get/iso2code/RU и проверяет, что в ответе в поле RestResponse.result.name содержится значение “ Russian Federation”
Кстати, код взят из оригинальной статьи и автоматически конвертирован из Java в Kotlin при его вставке в Idea. При этом некоторые инструкции (when, is) были экранированы при помощи символа «, так как они являются ключевыми словами в Kotlin.
Попробуем запустить тест.
Запуск тестов
Тесты можно запускать двумя способами: через JUnit и через Gradle.
Чтобы запустить тесты через JUnit, в Idea надо навести мышь на значок запуска слева от строки, в которой объявлен класс и выбрать Run Test:
После прогона тестов (в нашем случае одного теста), внизу окна Idea отобразится результат тестирования:
Теперь настроим запуск тестов через Gradle и в дальнейшем будем пользоваться этим способом запуска.
3. Выбираем Gradle project из выпадающего списка
Сохраняем изменения и запускаем тест при помощи Gradle. После прогона увидим результат:
Посмотрим, как выглядит упавший тест. Для этого поменяем в тесте код страны и запустим тест заново:
В логе можно увидеть причину падения:
Возвращаем код страны обратно на RU.
Теперь добавим несколько тестов, чтобы проверить поиск других стран.
Добавляем еще тесты
Добавим поиск США и Индии по их ISO-кодам:
Полную версию можно посмотреть тут.
Если посмотреть на код, то можно увидеть, что в нём повторяются одни и те же инструкции для каждого теста:
Чтобы избавиться от повторяющихся фрагментов кода, в нашем случае можно:
Первый вариант хотя и является самым очевидным, но он не такой гибкий, как остальные. Что если нам понадобится добавить еще пару проверок для других тестов?
Рассмотрим второй вариант.
В Serenity тесты принято разбивать на небольшие блоки кода, которые затем можно использовать повторно при необходимости. Эти блоки называются “шагами”. Применяя подобный принцип на практике, можно перейти от использования технических формулировок (“код http-ответа = 200” или “выполни http запрос”) к выражениям, понятным обычному человеку: “действие было успешным” или “выполни поиск”. Поэтому всегда лучше начинать с реализации маленьких шагов, описывающих какие-либо действия, а затем использовать их для создания более сложных шагов и сценариев. В общем, чтобы сделать тесты легко поддерживаемыми необходимо использовать принцип DRY (Don’t Repeat Yourself)
Выносим шаги в отдельный пакет
Создаем новый файл src/test/kotlin/steps/CountriesSearchSteps.kt :
Обратите внимание, все шаги, которые мы создали, ничего не возвращают, а для передачи параметров между ними используется приватная переменная.
Класс и его методы объявлены как open. Это необходимо, чтобы Serenity мог корректно сформировать отчёт, детализируя его пошагово.
Запускаем прогон тестов. Он должен завершиться успешно.
Теперь мы можем спокойно добавить дополнительный шаг и применить его в одном тесте.
Параметризованные тесты
Библиотека Serenity имеет встроенные механизмы для создания параметризованных тестов. Тестовые данные можно подгружать из csv-файла или задать в коде. Рассмотрим второй вариант.
Что необходимо сделать:
В итоге Serenity при инициализации тестового класса будет передавать в него очередную порцию тестовых данных и запускать все тесты внутри класса. К тестовым данным можно получить доступ через атрибуты класса.
Отчёты
Чтобы формировался отчет, необходимо использовать команду aggregate, которую мы добавили ранее при настройке запуска тестов через Gradle.
Сформированный отчет можно найти в каталоге target/site/serenity/. Переходим в этот каталог и открываем файл index.html:
В отчете можно увидеть шаги, которые выполнялись в каждом тесте и даже результаты http- запросов.
REST Assured как инструмент тестирования API
В современном мире существует множество инструментов для тестирования API, и сегодня речь пойдет об одном из представителей этого мира — инструменте Rest-Assured. На данный момент, это один из популярных инструментов для тестирования API, и различной информации о нем написано очень много, но мы хотели бы рассказать, чем именно он выделяется и как быстро начать писать на нем тесты.
Установка
Для начала определимся, что Rest-Assured это Java-библиотека для тестирования REST API. Подготовка и разбор документации может занять некоторое время, так как изначально рассматриваемый нами инструмент интуитивно не очень понятен, если “нырять в омут с головой” то можно потратить немало времени на начальном этапе.
Пожалуй, самый простой способ, с которым Rest-Assured работает и лучше всего визуализирует результаты — это работа в связке с Serenity (среда автоматизации тестирования с открытым исходным кодом). Для того чтобы начать писать тесты с помощью этого инструмента придется немного подготовиться. Для этого понадобится:
Далее, нужно создать проект Maven с базовой структурой в Idea:
После этого можно начать добавлять необходимые зависимости Maven в файл pom.xml. Для того чтобы в последующем было удобнее писать и запускать тесты, добавим следующие зависимости включающие JUnit и Serenity:
Также нам понадобится подключить несколько плагинов:
В итоге pom.xml файл проекта должен иметь следующий вид:
Все зависимости нужно заранее проверить на актуальность. Возможно, доступны обновленные версии.
С этого момента можно начинать писать свой первый тест.
Как видно, для начала работы с инструментом нужна небольшая, но все же требующая времени, подготовка. Такие инструменты для тестирования API как Postman дают вам все сразу и из коробки, буквально в одном приложении, что на начальном этапе дает легкость использования. С Rest-Assured же придется разбираться, хоть и недолго. В то же время инструмент дает то, чего нет у других инструментов — гибкость в кастомизации. Его можно использовать как отдельно, так и в связке с другими инструментами, например с вышеупомянутым Serenity для построения отчетов о тестировании.
Примеры
В качестве примера опишем несколько самых распространенных и используемых HTTP запросов — GET, POST, PUT и DELETE.
GET запрос
Для того чтобы написать и провести свой первый тест нам понадобится “Подопытный кролик”. Им может послужить Postman Echo, открытая документация от разработчиков другого инструмента тестирования API — Postman.
Давайте попробуем написать и выполнить для Rest-Assured следующий простой тест:
Для этого в проекте нужно создать новый Java class в папке src/test:
После чего написать сам GET запрос и тест. В случае с Rest-Assured тест будет иметь следующий вид:
Разберем данный пример:
Как видно из примера сам синтаксис написания тестов не очень сложен, что позволяет вам достаточно быстро написать тесты с помощью имеющейся у вас API документации.
POST запрос
Для написания этого запроса понадобится пример поинтереснее. Вместо Postman Echo будем использовать сервис для проверки запросов WebHook. Мы будем отправлять на этот ресурс запрос, после чего сможем увидеть, все ли отработало правильно. Для этого WebHook предоставляет нам уникальную ссылку для проверки наших запросов.
В случае Rest-Assured POST запрос будет выглядеть следующим образом:
В данном запросе изначально задается произвольная переменная someRandomString, которая будет использоваться в дальнейшем для заполнения тела запроса уникальными значениями. Далее создается новый JSON объект (requestBody), с помощью которого, в дальнейшем, задаются отправляемые нами параметры, такие как FirstName, LastName, UserName, Password и Email. С помощью request.post отправляется запрос на тот URL, что был сформирован на WebHook. После того как запрос отработает, мы можем вернуться к WebHook и убедиться, что запрос был отправлен корректно с теми параметрами, которые были указаны.
PUT запрос
По своей сути PUT и POST достаточно схожи, различие заключается в том, что если POST запрос записывает на сервер новую информацию, то PUT обновляет уже имеющуюся, но если объекта не было на сервере, то он создаст новый. Следовательно, и реализация этого метода будет не сильно отличаться от предыдущей. Так же не следует путать с PATCH, он аналогичен PUT, но применяется только к фрагменту ресурса
Для примера нашего PUT запроса мы воспользуемся другим сервисом для проверки — https://dummy.restapiexample.com/.
Реализация PUT запроса для Rest-Assured будет выглядеть следующим образом:
В данном примере можно увидеть, что переменная empid = 15410 — это то, что будет обновляться нашим запросом. После этого создается запрос, указывающий на конечную точку службы и создается JSON запрос, содержащий все поля, которые будут обновлены. С помощью request.put отправляется запрос, и проверяется, что ответ — 200. Все это, кроме самого первого шага, полностью перекликается с предыдущим запросом.
DELETE запрос
Исходя из прошлых примеров запрос Delete реализуется аналогично, лишь с небольшим изменением, вместо request.put следует использовать request.delete.
Общий вид запроса будет выглядеть в таком случае следующим образом:
При завершении выполнения запроса будет удалена запись, которую мы изменяли ранее (empid = 15410).
Для реализации тестов на Rest-assured хорошей практикой считается вынесение end-point’ов отдельно от тестов. Например, мы могли бы вынести наш baseURL с тестов, в отдельный класс:
И потом вызвать на уровне одного запроса посредством
Визуализация результатов
И все-таки, выполнять тесты — это еще недостаточно, очень важна так же визуализация результатов, которую предлагает тот или иной инструмент.
Rest-Assured в своем изначальном состоянии не может похвастаться приятной глазу отчетностью. Единственное, что мы можем увидеть при запуске тестов — это результат выполнения теста:
Да, конечно, мы можем улучшить это — например, с помощью уже упомянутого ранее Serenity можно сделать так, чтобы по прошествии тестов открывалась web страница с отчетностью. При работе в распределенной команде это будет крайне важно, ведь это даст возможность отправить отчет по пройденным тестам кому угодно в приятном для понимания и восприятия виде.
Для построения наглядной отчетности мы уже прописали Serenity в наш pom.xml файл. Теперь же будет достаточно прописать @RunWith(SerenityRunner.class)перед тестами и в консоли запустить команду mvn clean verify. После выполнения команды в папке target вашего проекта создастся папка site с файлом index.html внутри, в котором будет лежать отчет примерно следующего формата:
В отчете будут отображены тесты (выполненные, успешные и провалившиеся), а также, один общий отчет, и отчет по каждому тесту в отдельности.
Целевая направленность
Если у вас уже есть UI автотесты, написанные например на Selenium + Java, то вам скорее всего хотелось бы создавать, хранить и выполнять все тесты одновременно, и при необходимости подключать API тесты. Для этого и существует такой инструмент как Rest-Assured. Мы можем объединять все автотесты в одном месте, запускать их на сервере, чтобы они проходили все время, а также, при сборке продукта. Это удобно, если тестов много, или приходится часто обращаться к регрессии. Иметь несколько инструментов на отдельные тесты, запускать их в разное время, смотреть разные отчеты становится неудобно, соразмерно росту числа ваших автотестов.
Исходя из всего, что было написано, можно сделать вывод, что, на начальном этапе Rest-Assured не самый легкий в освоении инструмент. Также он не очень подходит как отдельный инструмент для тестирования, или если нет большого регресса в API тестах. В то же время, инструмент будет очень удобен, если имеются UI автотесты и нужно автоматизировать API кейсы. Использование Rest-Assured в этой роли поможет сделать все как можно удобнее и легче, нежели использование отдельного инструмента. Также в связке с другими инструментами, такими как Serenity, он достаточно гибкий и имеет широкий потенциал для использования в автотестах.