Трудности тестирования микросервисов¶
Микросервисное приложение — распределенная система, и межпроцессное взаимодействие играет одну из ключевых ролей.
Очень важно, чтобы разработчики писали тесты, которые проверяют, как он взаимодействует со своими зависимостями и клиентами.
Как говорилось, сервисы могут общаться между собой, применяя разнообразные стили и механизмы IPC. Вот, к примеру, схема взаимодействия некоторых сервисов.
Разработчик сервиса должен быть уверен в стабильности API, которые потребляет сервис. По этой же причине не следует вносить ломающие изменения в API собственного сервиса.
Чтобы проверить, способны ли два сервиса взаимодействовать, можно обратиться к API, который инициирует взаимодействие, и убедиться, что он возвращает ожидаемый результат. Но это будет сквозной тест. Скорее всего, будут вызываться промежуточные зависимости, отрабатывать бизнес-логика и т.п., тогда как цель — проверка относительно низкоуровнего механизма IPC. Нужны тесты, которые проверяют работу сервисов изолированно. В качестве решения можно воспользоваться тестированием контрактов в расчёте на потребителя.
Тестирование контрактов в расчёте на потребителя¶
Пусть есть команда, пишушая API-шлюз, который, помимо прочего, обращается к точке REST GET /orders/{orderId}. В этом случае крайне важно иметь тесты, которые проверяют согласованность API между шлюзом и сервисом Order. В терминах тестирования контрактов между этими двумя сервисами имеется связь “потребитель (consumer) — провайдер”.
Команда, пишущая код потребителя, также пишет набор тестов для контракта и добавляет его к остальным тестам провайдера, например, через merge-request. Эти тесты выполняются в процессе развертывания сервиса Order.
Взаимодействие между потребителем и провайдером определяется набором примеров сообщений, которые называются контрактами. Скажем, контракт для REST API состоит из примеров HTTP-запроса и ответа.
Несмотря на то, что основной задачей является проверка провайдера, контракты также проверяют, соответствует ли им потребитель. Например, потребительский контракт для REST-клиента конфигурирует заглушку сервиса, которая проверяет, совпадает ли HTTP-запрос с запросом контракта, и возвращает обратно его HTTP-ответ. Это Тестирование контрактов на стороне потребителя.
Для тестирования контрактов существует два популярных фреймворка:
- семейство Pact с поддержкой разных языков
- Spring Cloud Contract
Дата создания : 31 июля 2022 г.