Контрактное тестирование фокусируется на проверке взаимодействия между микросервисами на уровне их API (контракта). Цель — убедиться, что потребитель (сервис, использующий API) и поставщик (сервис, предоставляющий API) соблюдают определенный "контракт" (схему запросов/ответов, формат данных, ожидания).
Основные принципы:
- Потребитель-движет: Тесты основаны на ожиданиях потребителя. Потребитель определяет, какие данные и форматы ему нужны.
- Двустороннее тестирование: Проверяется как сторона потребителя (умеет ли он работать с текущим контрактом), так и сторона поставщика (соответствует ли его реализация ожиданиям потребителя).
- Быстрота: Тесты выполняются быстро, часто в рамках конвейера CI/CD, так как не требуют развертывания всех зависимых сервисов.
Процесс обычно включает:
- Потребитель создает тесты, описывающие свои ожидания от API поставщика. Эти тесты генерируют "контракт".
- Контракт публикуется (например, в централизованном репозитории).
- Поставщик использует опубликованный контракт для верификации своей реализации API. Он запускает тесты (обычно на стороне поставщика), которые проверяют, соответствует ли его API контракту.
- В случае расхождения между ожиданиями потребителя и реализацией поставщика, тест падает, указывая на нарушение контракта.
Инструменты:
- Pact (наиболее популярный)
- Spring Cloud Contract
- Swagger/OpenAPI с инструментами валидации
Преимущества:
- Раннее выявление ошибок интеграции: Проблемы с совместимостью обнаруживаются еще до развертывания.
- Уменьшение необходимости интеграционных тестов: Снижает зависимость от сложных и медленных сквозных тестов.
- Независимое тестирование: Позволяет тестировать сервисы независимо друг от друга.
- Четкое определение ожиданий: Явно определяет контракт между сервисами.
Недостатки:
- Не заменяет полностью интеграционные тесты (только проверяет взаимодействие на уровне API).
- Требует дисциплины в версионировании контрактов.
- Может быть сложнее для сервисов с очень сложными контрактами.
Пример использования с Pact:
- Потребитель (например, сервис
Order Service) использует библиотеку Pact для создания consumer-side тестов.
java
- При выполнении consumer-side тестов генерируется файл контракта (
.json файл).
- Этот файл контракта публикуется в сервис Pact Broker или другой централизованный репозиторий.
- Поставщик (
Product Service) использует библиотеку Pact (например, Pact Provider Verifier) для верификации своей реализации API на основе контракта, полученного из Pact Broker.
java
- verifier на стороне поставщика вызывает реальный API поставщика согласно спецификации контракта и сравнивает полученный ответ с ожидаемым в контракте.
Контрактное тестирование является важной практикой для обеспечения надежности и поддерживаемости систем на базе микросервисов.