Это первый блог из серии о тестированиях контракта потребителя сервиса. В этой серии представлена концепция и продемонстрировано написание тестов контрактов для приложения spring boot.
В мире микросервисов мы часто говорим об их преимуществах. Однако есть определенные условия, которые должны быть соблюдены, прежде чем выбрать этот архитектурный паттерн. Блог Мартина Фаулера очень хорошо освещает эти требования. Одним из условий, о которых он упоминает, является ContinuousDelivery. ContinuousDelivery — это технология разработки программного обеспечения, при которой вы создаете его таким образом, что оно может быть запущено в любое время. В контексте микросервисов непрерывная доставка (continuous delivery) означает, что любой сервис может быть внедрен в производство в любое время вне зависимости от остальных микросервисов. Но что гарантирует, что развертывание нового микросервиса не повлияет на общую функциональность приложения? Конечно, тестирование. Однако мы не хотим запускать все приложение, которое может состоять из сотен микросервисов, только для того, чтобы протестировать крошечное изменение кода в одном из сервисов. Так что же нам делать?
Прежде чем решать проблему, давайте сделаем шаг назад. Зачем нам нужны другие микросервисы для тестирования крошечного изменения кода в одном из сервисов? Ответ заключается в том, что сервисы взаимодействуют друг с другом для достижения общей цели. И нам нужно убедиться, что изменение кода не нарушит существующую функциональность. На самом деле достаточно убедиться, что изменение кода не повлияет на API сервиса. Если API сервиса не поврежден, то можно с уверенностью предположить, что потребительские микросервисы этого конкретного сервиса будут работать правильно. Так мы можем избежать запуска всего приложения для тестирования изменений в сервисе. Но каким способом будет проверяться целостность API сервиса? Ответ — с помощью тестирования контракта. Давайте рассмотрим простой пример, чтобы лучше это понять.
Простая система предоставления займов
Пример намеренно упрощен, чтобы сосредоточиться на тестировании контрактов. Экосистема работает следующим образом.
Пользователь подает заявку на получение кредита, обращаясь к API шлюза
API шлюза получает фрод-статус по протоколу Http.
Как только фрод-статус получен, он эмитирует событие о предоставлении кредита.
Ожидается, что сервис предоставления займа сможет прослушать это событие и выполнить дальнейшую обработку.
Сервисы Loan Gateway, Fraud Service и Loan Fulfillment разрабатываются и развертываются отдельно как микросервисы. Можно предположить, что для передачи сообщений используется Kafka. Ниже приведена пирамида тестов для этих сервисов, которая выглядит следующим образом
Глядя на пирамиду тестов, можно понять, что модульные и интеграционные тесты для каждого сервиса являются независимыми. Однако функциональный набор является общим, это связано с тем, что нам нужно убедиться, что система в целом работает, когда все микросервисы связаны друг с другом.
Проблема такого подхода заключается в том, что теперь уже нельзя утверждать, будто эти микросервисы являются независимыми. Это обусловлено тем, что для развертывания любого сервиса нужно запустить функциональный набор, который зависит от работы всех остальных сервисов.
Ниже показано, как выглядит CI-пайплайн кредитного шлюза.
Что если мы сможем устранить зависимость от других сервисов? Что если на этапе сборки мы убедимся, что интеграция с другими службами пройдет нормально? Если мы сможем этого добиться, то пайплайн будет выглядеть следующим образом.
Желтые квадратики исчезнут. Это то, что мы получим, применив тестирование контрактов.
Тест контракта проверяет, соблюдает ли сервис контракт с другими сервисами или нет. Контракт — это соглашение между сервисом-потребителем и сервисом-поставщиком. Коммуникационная среда между сервисами может быть синхронной или асинхронной. Обе среды могут быть проверены с помощью тестов контрактов.
Тестирование контракта потребителя сервиса
Как следует из названия, потребитель создает контракт, описывающий его ожидания от службы-поставщика. Служба провайдера выполняет контракт, предоставленный потребителем, и убеждается, что ожидания потребителя оправдались. Если ожидания не удовлетворяются, то провайдер уже не может что-либо изменить.
На этом пока все. В следующем блоге мы рассмотрим, как писать тесты для контрактов потребителей сервиса, используя Pact для синхронного взаимодействия.
Материал подготовлен в рамках курса «Разработчик на Spring Framework». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.