И тест на REST Assured будет выглядеть вот так. В качестве библиотеки для сравнения я возьму готовую библиотеку Retrofit, которая есть в OpenAPI Generator и Swagger Codegen. Так выглядит код теста, написанного на Retrofit. Итак, мы получили все переменные, написали все шаблоны и соответственно сделали pull request в Swagger Codegen. Давайте разберёмся теперь с генерацией клиента.
Между PUT и PATCH запросами скорость зависит от того, как реализована логика сервера. В целом, PATCH-запросы могут быть быстрее, так как они могут передавать только измененные поля объекта. Мы можем красить build в красный цвет и тем самым стимулировать разработчиков писать тесты. После генерации у нас в папке target возникают такие тесты. Это реальный тест «на 200», его можно запустить.
Этого метода в API api.pet нет — и получаем ошибку компиляции. Удаление или изменение спецификации может сломать компиляцию клиента. Мы этот параметр используем в тесте, но его уже нет в клиенте.
Фреймворк — набор инструментов и правил, которым по сути является Swagger. Часть инструментов доступна бесплатно и имеет открытый исходный код, еще часть — платная и предназначена для компаний. Часто можно встретить термины Swagger и OpenAPI в одном контексте, но было бы правильно их разделить. Если простыми словами описать различия, то Swagger — это коммерческий продукт и спецификация версии 2.0, и он относится к инструментам API. А OpenAPI — это бесплатная спецификация Swagger версии three.0 и выше.
Как Запускать Коллекции Тестов
Сейчас у Postman есть расширение для Chrome и версия для декстопа под все популярные операционные системы. Укажем значение Iterations равным 10 и пройдём наши тесты. Запрос вновь прошёл успешно, значит, всё сделали правильно. После того как мы использовали параметры из переменных окружения, повторим запрос, чтобы проверить, что нигде не ошиблись. Сохраняем созданное окружение кнопкой Add.
В Swagger Codegen с переходом на другой template-engine остался один Retrofit-клиент. REST Assured-клиента на данный момент нет, но есть открытое problem на его возвращение. Метод, который получится в Retrofit, будет выглядеть вот так. Далее мы используем response specification — это особенность REST Assured. И валидируем сразу ответ, проверяем, что код — 200.
Возникает ошибка компиляции, потому что мы добавили ещё один параметр, о котором мы ничего не знаем конкретно в этом методе. Когда мы только всё начинали, мы рассматривали множество клиентов в Swagger Codegen, написанных под разные языки, но ни один нас не устроил. Все эти клиенты очень жёстко привязаны к документации. В них мало точек расширения, и они не рассчитаны на то, что наша спецификация будет меняться. Мы решили, что напишем свой API-клиент, который будет обладать всеми необходимыми для нас возможностями.
У нас единое наименование на основе OpenAPI-спецификации. Из-за этого единообразия мы пришли к тому, что наши автотесты могут писать все. Их могут писать автоматизаторы тестирования и понимать ручные тестировщики и разработчики. Всю эту красоту мы вынесли в шаблон проекта с автотестами. Например, у наших спецификаций есть модели.
Например, можно сгенерировать клиента на основе шаблонизатора mustache, который с помощью шаблонов убирает ограничения на используемый язык в генерируемых файлах клиента. Тест после генерации будет выглядеть так. Здесь значения x-example такие же, как и в спецификации. Осталось добавить реальных тестовых данных и можно его использовать. В REST Assured нетипизированные параметры. У Retrofit ответ всегда мапится на ответ из спецификации по умолчанию.
Как Получить Openapi-спецификацию
Для каждого реквеста вы можете получить информацию в формате OpenAPI-спецификации. Далее мы агрегируем всю информацию из реквестов, сравниваем с исходной спецификацией и получаем protection. У нас генерируются тестовые классы, мы можем поправить их в target, запустить и использовать. Через IDE нажимаем клавишу F6, и у нас возникает окошко. Поменяется только одна константа внутри нашей операции. Это неожиданно и ломает все представления об автотестах.
В REST Assured ответ может мапиться на ответ из спецификации, а может не мапиться. Потому что, если мы тестируем невалидные кейсы, например, статус-коды не 200, то нам бы хотелось как-то кастомизировать наш ответ, чтобы получать что-то невалидное. Сама генерация клиента в OpenAPI Generator основана на mustache template (Logic-less Mustache engine). Это круто, потому что генерация не зависит от языка программирования. Вы можете использовать mustache-шаблоны как для C#, так и для С++, так и для любого языка и получить клиент. Ещё один плюс — эти клиенты легко добавлять.
В этом выпуске показал инструмент, который поможет тестировщикам измерить качетсво тестов для API на основе Swagger спецификации. Спецификации можно написать в редакторе Swagger Editor. Но спецификацию OpenAPI можно генерировать на основе Swagger-annotation автоматически. OpenAPI может быть использована разработчиками для обеспечения согласованности/стандартизации разработки REST API. Она также является хорошим документом для описания реализованной API для тестирования. Условно, у вас будет описан endpoint с типом запроса Post с полями А и В.
Поняв, что дублируем много кода и он очень громоздкий, мы написали свою обвязку над HTTP client-ом. Когда появились специализированные инструменты для автоматизации и появился REST Assured, мы начали его использовать. Потом мы осознали, что его тоже неудобно использовать, и написали свою обвязку над REST Assured. Swagger — это набор инструментов, который позволяет автоматически описывать API на основе его кода. API — интерфейс для связи между разными программными продуктами, и у каждого проекта он свой. Документация, автоматически созданная через Swagger, облегчает понимание API для компьютеров и людей.
Таким образом, у нас было очень много автотестов сомнительного качества. Они были понятны только тем, кто их пишет, тестовые клиенты моментально устаревали, а поддерживать их было некому. И главное, разработка не участвовала в тестировании.
В Postman можно создать такие автоматические тесты за несколько шагов на основе готовых сниппетов (заранее написанных скриптов). Для этого вернемся к предыдущему запросу и перейдем во вкладку «Test». API — это набор правил, с помощью которых программы обмениваются данными друг с другом.
Как Ускорить Тестирование Приложения С Помощью Openapi-спецификаций
По факту мы получили «фабрику» автотестов, используя которую стало легко добавлять автотесты на любой проект. Основная идея, что mustache-темплейты — logic-less, и тяжёлую логику нельзя таким образом сгенерировать. И потому это не совсем реальные тесты, а шаблоны тестов. Но дописав логики, вы получите вполне реальные тесты. Нам пришла идея, почему бы не использовать свои темплейты.
- Swagger-diff — это opensource-проект, который помогает сравнить две спецификации.
- Всю эту красоту мы вынесли в шаблон проекта с автотестами.
- У вас есть в коде модели, эти модели переносятся в OpenAPI-спецификацию, из OpenAPI-спецификации у нас генерятся bean-ы и на эти bean-ы мы генерим assertions.
- В стандартном Retrofit-клиенте параметры типизированы, для тестирования это не очень удобно.
- И у нас были разработчики, которые писали в основном юнит-тесты, интеграционные тесты.
- OpenAPI рассматривается как универсальный интерфейс для пользователей (клиентов) по взаимодействию с сервисами (серверами).
Мы можем попробовать сгенерировать assertions на модели ответов с помощью плагина. У вас есть в коде модели, эти модели переносятся в OpenAPI-спецификацию, из OpenAPI-спецификации у нас генерятся bean-ы и на эти bean-ы мы генерим assertions. Три года назад картина у нас была следующая. У нас были автоматизаторы тестирования, которые имели достаточно стандартный подход и писали автотесты на Apache HTTP-клиенте. У нас были ручные тестировщики, которые не могли писать достаточно сложный код, поэтому использовали инструменты в виде Postman и писали автотесты, используя JavaScript. И у нас были разработчики, которые писали в основном юнит-тесты, интеграционные тесты.
Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results. У Postman есть графический интерфейс, что выгодно отличает его от ряда других инструментов тестирования.
Чтобы проект заработал, нам достаточно поменять значения двух property, и получаем готовые тесты и сгенерированные клиенты. На самом деле мы пытаемся генерировать клиент из спецификации, которая на это не рассчитана. Данная спецификация использовалась только для ручное тестирование api Swagger UI, а мы хотим получить клиент. И мы можем получить что-то невразумительное. Вместо методов вашего тестового клиента у вас будут route1, route2, route16. Позже мы поняли, что можно генерировать не только bean-ны, assertion-ы, но ещё и тестовый клиент.
Основное назначение Swagger — автоматически генерировать документацию, понятную для людей и для машин. Соответственно, чаще всего он применяется, чтобы быстро и легко документировать код API. Обычно https://deveducation.com/ используется в связке с архитектурой RESTful API. Как можно увидеть, спецификации OpenAPI и инструменты Swagger Editor/Swagger являются неотъемлемыми атрибутами в процессе тестирования API.
Postman — это популярный инструмент для тестирования API. Тесты API также можно использовать для ускорения UI-тестирования. Наиболее распространенный пример – это метод авторизации. Основная цель Swagger — это документирование API. Основная цель Postman — это тестирование. В swagger, в отличие от postman нельзя писать автотесты, создавать коллекции, переменные, запускать run-ы и т д.