Тестирование Api С Помощью Swagger: Как Проверить Функциональность Api - Media and Information Literacy Initiative, Bangladesh

Тестирование Api С Помощью Swagger: Как Проверить Функциональность Api

লেখাটি শেয়ার করো

Здесь значения x-example такие же, как и в спецификации. Осталось добавить реальных тестовых данных и можно его использовать. Основная идея, что mustache-темплейты — logic-less, и тяжёлую логику нельзя таким образом сгенерировать. И потому это не совсем реальные тесты, а шаблоны тестов. Но дописав логики, вы получите вполне реальные тесты. Поменяется только одна константа внутри нашей операции.

В нем представлены образцы Swagger Core из библиотеки Java. Каждый образец содержит файл Readme, в котором подробно описано, как его запускать и что проверять. Чтобы пользоваться вторым подходом, нужно знать синтаксис Swagger. Описания можно готовить в формате YAML/JSON. Можно упростить эту задачу, используя Swagger Editor.

swagger для тестировщика

А некоторые вообще не понимали, зачем нужны автотесты, так как считали, что ничего не сломается. Я занимаюсь автоматизацией тестирования в Яндексе с 2013 года. Из них более четырёх лет автоматизирую тестирование REST API-сервисов. Для тестировщиков головная боль — именование тестовых методов и тестовых классов. У нас единое наименование на основе OpenAPI-спецификации. Из-за этого единообразия мы пришли к тому, что наши автотесты могут писать все.

REST Assured-клиента на данный момент нет, но есть открытое problem на его возвращение. В том же REST Assured мы использовали builder-паттерн, и у каждого вызова параметра собственный метод. И тест на REST Assured будет выглядеть вот так. В качестве библиотеки для сравнения я возьму готовую библиотеку Retrofit, которая есть в OpenAPI Generator и Swagger Codegen.

Swagger: Что Это Такое И Как С Ним Работать?

В стандартном Retrofit-клиенте параметры типизированы, для тестирования это не очень удобно. Нам бы хотелось, чтобы параметры были не типизированы, и мы могли вставить любые параметры, получить ошибку и её валидировать. Также вы получите другие различные проблемы. Например, опечатки, потому что Swagger Annotation пишется руками разработчиков. Опечатки можно поправить — это не проблема.

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

В какой-то момент пришёл менеджер и сказал, что мы больше не будем релизить новые REST API-сервисы без спецификаций. Зачем мы вообще используем спецификацию? Всё благодаря этой замечательной странице Swagger UI. Человеческая жизнь слишком коротка, чтобы тратить ее на интеграцию и документацию.

Как Правильно Генерировать Клиент Swagger?

Самый простой способ — написать её в текстовом файлике. Давайте подробнее разберём, что она собой представляет. Мы там ставим версию нашего API, устанавливаем хосты, базовые пути, схемы и прочее. Также у нас есть блок с описанием всех возможных операций, в которых мы указываем параметры и все возможные ответы. У нас во всех проектах есть спецификации. В основном это спецификации двух версий — это OpenAPI-спецификации v1.0 и OpenAPI-спецификации v2.0.

Релизы в Swagger Codegen были довольно редкие, тесты часто падали и комьюнити это не устраивало. Наш Swagger UI и строится на основе этого файла спецификации — swagger.json. OpenAPI-спецификация — это opensource-проект, описывающий спецификацию и поддерживаемый линукс-сообществом (Linux Foundation Collaborative Project). Это популярный проект, у него звёздочек на GitHub. API (Application Programming Interface) — это набор процедур, протоколов и инструментов, позволяющих разным программным приложениям общаться между собой.

Это неожиданно и ломает все представления об автотестах. Они должны ловить такие случаи, но сейчас получается, что всё работает. Чтобы отлавливать такие случаи, мы используем diff-спецификации, о которых чуть позже. Удаление или изменение спецификации может сломать компиляцию клиента.

swagger для тестировщика

На GitHub создали project-template, где указали клиент, модуль с тестами, настроили генерацию. Если нам нужен проект автотестов на какой-то новый сервис, мы берём и наследуемся от этого шаблона. Чтобы проект заработал, нам достаточно поменять значения двух property, и получаем готовые тесты и сгенерированные клиенты.

Их могут писать автоматизаторы тестирования и понимать ручные тестировщики и разработчики. Всю эту красоту мы вынесли в шаблон проекта с автотестами. В REST Assured нетипизированные параметры. У Retrofit ответ всегда мапится на ответ из спецификации по умолчанию.

Проблемы, С Которыми Мы Столкнулись При Генерации

Мы этот параметр используем в тесте, но его уже нет в клиенте. Для каждого из методов HTTP Swagger позволяет описать параметры запросов и формат ответов. У нас собрался build, и запустился Swagger-diff, и мы уже заранее знаем на этом этапе, сломалась ли обратная совместимость и изменилось ли что-нибудь.

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

Мы можем проверять в тестах, что наш ответ после запроса соответствует определённой модели, которая описана в спецификации. Но в реальности это очень маленькое, узкое покрытие. Мы проверяем только модели и не проверяем значения.

  • В данной публикации рассмотрим подробнее Swagger, позволяющий создавать, документировать и тестировать API.
  • Для взаимодействия с любой программой используется API.
  • После генерации у нас в папке goal возникают такие тесты.
  • Это оценили наши тестировщики, которые могут, не используя Curl, тестировать релиз.
  • У нас есть механизм в REST Assured Response и Request specification.

Итак, мы получили все переменные, написали все шаблоны и соответственно сделали pull request в Swagger Codegen. Когда мы только всё начинали, мы рассматривали множество клиентов в Swagger Codegen, написанных под разные языки, но ни один нас не устроил. Все эти клиенты очень жёстко привязаны к документации. В https://deveducation.com/ них мало точек расширения, и они не рассчитаны на то, что наша спецификация будет меняться. Мы решили, что напишем свой API-клиент, который будет обладать всеми необходимыми для нас возможностями. Например, вот доклад технического писателя из «Яндекса» о том, что такое вообще API и как работать со Swagger.

Самые полезные команды — generate и validate. Первая позволяет создать клиент, а вторая — проверить его соответствие спецификации. Посмотреть полный список возможностей можно с помощью команды help после запуска jar-файла. Это проект для автоматического генерирования клиентских библиотек API, заглушек сервера и документации. Поддерживает большое количество технологий. Посмотреть полный список можно в репозитории Swagger Codegen на GitHub.

Для каждого реквеста вы можете получить информацию в формате OpenAPI-спецификации. Далее мы агрегируем всю информацию из реквестов, сравниваем с исходной спецификацией и получаем coverage. Здесь пример теста, который просто сравнивает эти два ответа. У нас есть функция, которую принимает API-клиент и возвращает ответ, который мы сравниваем через matcher jsonEquals. Нам пришла идея, почему бы не использовать свои темплейты. Тогда мы получим шаблоны тестов, которые можно использовать и писать.

ручное тестирование api

Мы можем красить construct в красный цвет и тем самым стимулировать разработчиков писать тесты. Так же выглядят и теги — это группа операций. Мы можем понять, сколько операций покрывается, сколько вообще не покрыты. Ещё есть фильтры по условиям, можем посмотреть, какие условия не покрываются совсем. После генерации у нас в папке goal возникают такие тесты.

Обращает на себя внимание краткость документации, реализованной с помощью Swagger. Это объясняется тем, что сам по себе Swagger UI предназначен для интерактивного взаимодействия. Нет смысла читать пространные описания, когда можно просто выполнять указанные запросы и проверять, какие ответы приходят.

Так выглядит код теста, написанного на Retrofit. В качестве библиотеки мы выбрали REST Assured. Она имеет fluent interface, эта библиотека предназначена для тестирования.

আরও লেখা পড়ো

10 Best White Label Forex Brokers 2024

Tamta’s writing is both professional and relatable, ensuring her readers gain valuable insight and knowledge. Customized your prop

ইন্টারনেটে নিরাপত্তা নিয়ে তোমার ভাবনা লিখে পাঠাও

জিতে নাও পুরষ্কার