В качестве библиотеки для сравнения я возьму готовую библиотеку Retrofit, которая есть в OpenAPI Generator и Swagger Codegen. Так выглядит код теста, https://deveducation.com/ написанного на Retrofit. В качестве библиотеки мы выбрали REST Assured. Она имеет fluent interface, эта библиотека предназначена для тестирования.
Это тоже экономило много времени и делало клиент единообразным. У нас уменьшалось время внедрения людей в новый проект автотестов. Затем мы решили не генерировать bean-ы, а сразу брать их напрямую из кода и генерировать их в проекте автотестов. Из неё нам понятно, какой перед нами API, понятны все операции, понятно, как API используется и что вернётся. Более того, через эту страницу можно делать запросы и получать ответы.
Подключение Swagger К Проекту
В ней есть механизм Request specification и Response specification. Это произошло в связи с независимым развитием Swagger Codegen 3.X и Swagger Codegen 2.X. Из-за этого нарушилась обратная совместимость. Очень много клиентов исчезли и не были поддержаны.
Тест после генерации будет выглядеть так. Здесь значения x-example такие же, как и в спецификации. Осталось добавить реальных тестовых данных и можно его использовать. Поменяется только одна константа внутри нашей операции.
Получалось, что все члены команды имели разные подходы к автоматизации тестирования. К тому же есть ещё одна важная проблема — наши REST API активно развиваются. Это означает, что при новых релизах в наших сервисах нам нужно править тестовый клиент. По факту у нас происходит гонка нашего тестового клиента и REST API. Скажем так, у нас есть несколько десятков REST API и несколько десятков тестовых клиентов, которые нужно поддерживать.
Тест-дизайн
Это достаточно легко решается, если к модели добавить имя пакета. И ещё одна проблема — неполнота спецификаций. Скоро вы обнаружите, что в вашем API есть внутренние операции, о которых вы не знали, но которые тоже надо тестировать. Самое приятное, что всё это легко исправляется. Давайте подробнее разберём, что она собой представляет. Мы там ставим версию нашего API, устанавливаем хосты, базовые пути, схемы и прочее.
Это неожиданно и ломает все представления об автотестах. Они должны ловить такие случаи, но сейчас получается, что всё работает. Чтобы отлавливать такие случаи, мы используем diff-спецификации, о которых чуть позже.
Вам надо только добавить набор mustache-шаблонов, и у вас готовый клиент. И третья очень крутая фича — эти клиенты очень легко кастомизировать. Достаточно добавить свои шаблоны, которые просто будут использоваться при генерации. Три года назад картина у нас была следующая. У нас были автоматизаторы тестирования, которые имели достаточно стандартный подход и писали автотесты на Apache HTTP-клиенте.
Когда появились специализированные инструменты для автоматизации и появился REST Assured, мы начали его использовать. Потом мы осознали, что его тоже неудобно использовать, и написали свою обвязку над REST Assured. В данной публикации рассмотрим подробнее Swagger, позволяющий создавать, документировать и тестировать API. С помощью Swagger можно узнать доступные эндпоинты, параметры запросов и формат ответов.
Вы в нем описываете вашу спецификацию, там есть удобный редактор, который сразу её валидирует. В правой части она у вас отображается в красивом виде. Наш Swagger UI и строится на основе этого файла спецификации — swagger.json.
- Форма детальной информации о REST-сервисе и возможности отправки запроса.
- Нужно добавить парочку темплейтов, и получим тесты.
- Поняв, что дублируем много кода и он очень громоздкий, мы написали свою обвязку над HTTP client-ом.
- И третья очень крутая фича — эти клиенты очень легко кастомизировать.
- Для явного указания объекта ответа можно использовать аннотацию @ApiResponse.
Понятно, что если мы добавим параметры, как я рассматривал раньше, всё будет хорошо. Далее мы используем response specification — это особенность REST Assured. И валидируем сразу ответ, проверяем, что код — 200. Есть API-клиент, есть вызов Story API и метод getInventory. Когда мы только всё начинали, мы рассматривали множество клиентов в Swagger Codegen, написанных под разные языки, но ни один нас не устроил. Все эти клиенты очень жёстко привязаны к документации.