Swagger Openapi Specification Как Основа Для Ваших Приёмочных Тестов Хабр

Необходимо понимать, с каким опытом мы пришли к этой задаче. Давайте поговорим об эволюции автотестов, которую мы прошли. Изначально мы писали автотесты на Apache HTTP shopper. Поняв, что дублируем много кода и он очень громоздкий, мы написали свою обвязку над HTTP client-ом.

Они в свою очередь также могут содержать дополнительные ветви, содержащие описание операций, параметры запросов и схемы ответов. Для каждого из методов HTTP Swagger позволяет описать параметры запросов и формат ответов. Аналогично можно сгенерировать тесты для параметров и моделей. Вы просто проходите по всем параметрам и добавляете шаблоны тестов, чтобы для каждого параметра сгенерировались аналогичные тесты. На самом деле мы пытаемся генерировать клиент из спецификации, которая на это не рассчитана. Данная спецификация использовалась только для Swagger UI, а мы хотим получить клиент.

Опционально описание тегов можно задать в отдельном разделе описания всей документации. Чаще всего используются schemas https://deveducation.com/ и responses. Headers, securitySchemes, parameters − вторые по частоте использования в документации, которую я видел.

Наиболее Популярные И Эффективные Инструменты Для Тестирования Api:

Для того чтобы настроить генерацию тестов, нам надо прописать template_directory с нужными темплейтами и добавить шаблон для тестов. В Swagger Codegen с переходом на другой template-engine остался один Retrofit-клиент. REST Assured-клиента на данный момент нет, но есть открытое problem на его возвращение.

Например, есть версия v1.x, v2.x и vN.x. То есть у нас получается два , для версии v1 и для версии v2.

Internet Ui

Тест после генерации будет выглядеть так. Здесь значения x-example такие же, как и в спецификации. Осталось добавить реальных тестовых данных и можно его использовать. Поменяется только одна константа внутри нашей операции.

Возникает ошибка компиляции, потому что мы добавили ещё один параметр, о котором мы ничего не знаем конкретно в этом методе. Там есть и клиент, и тест, даже скрипт, который пушит код на GitHub. По факту этот проект уже можно использовать. Но как только вы его начнёте использовать, то поймёте, что что-то идёт не так. Ниже реальный пример, где я использовал генерацию кода.

Вы в нем описываете вашу спецификацию, там есть удобный редактор, который сразу её валидирует. В правой части она у вас отображается в красивом виде. Наш Swagger UI и строится на основе этого файла спецификации — swagger.json.

• Чтобы проект заработал, нам достаточно поменять значения двух property, и получаем готовые тесты и сгенерированные клиенты.
• Мы можем проверять в тестах, что наш ответ после запроса соответствует определённой модели, которая описана в спецификации.
• Мы этот параметр используем в тесте, но его уже нет в клиенте.
• Так же выглядят и теги — это группа операций.

OpenAPI-спецификация — это opensource-проект, описывающий спецификацию и поддерживаемый линукс-сообществом (Linux Foundation Collaborative Project). Это популярный проект, у него звёздочек на GitHub. Человеческая жизнь слишком коротка, чтобы тратить ее на интеграцию и документацию. Обязательность можно указать для конкретной схемы. Например, у есть запрос на запись и возврат, и на post запрос мы хотим сделать обязательными ряд полей. Поэтому можно описывать какие-то важные вещи прямо в описании запроса.

Вместо кода, где у нас не типизированные assertions, а стандартные hamcrest матчеры, мы получаем типизированные assertions — более удобные и понятные. Если у нас кроме модели ещё есть примеры значений параметров, то можем попробовать сгенерировать реальные шаблоны тестов и сами тесты. Нужно добавить парочку темплейтов, и получим тесты. Позже мы поняли, что можно генерировать не только bean-ны, assertion-ы, но ещё и тестовый клиент. Мы стали генерировать клиент на основе RAML-спецификации.

Это достаточно легко решается, если к модели добавить имя пакета. И ещё одна проблема — неполнота спецификаций. Скоро вы обнаружите, что в вашем API есть внутренние операции, о которых вы не знали, но которые тоже надо тестировать. Самое приятное, что всё это легко исправляется. Давайте подробнее разберём, что она собой представляет. Мы там ставим версию нашего API, устанавливаем хосты, базовые пути, схемы и прочее.