Это первый блог из серии о тестированиях контракта потребителя сервиса. В этой серии представлена концепция и продемонстрировано написание тестов контрактов для приложения spring boot.
В мире микросервисов мы часто говорим об их преимуществах. Однако есть определенные условия, которые должны быть соблюдены, прежде чем выбрать этот архитектурный паттерн. Блог Мартина Фаулера очень хорошо освещает эти требования. Одним из условий, о которых он упоминает, является ContinuousDelivery. ContinuousDelivery — это технология разработки программного обеспечения, при которой вы создаете его таким образом, что оно может быть запущено в любое время. В контексте микросервисов непрерывная доставка (continuous delivery) означает, что любой сервис может быть внедрен в производство в любое время вне зависимости от остальных микросервисов. Но что гарантирует, что развертывание нового микросервиса не повлияет на общую функциональность приложения? Конечно, тестирование. Однако мы не хотим запускать все приложение, которое может состоять из сотен микросервисов, только для того, чтобы протестировать крошечное изменение кода в одном из сервисов. Так что же нам делать?
Прежде чем решать проблему, давайте сделаем шаг назад. Зачем нам нужны другие микросервисы для тестирования крошечного изменения кода в одном из сервисов? Ответ заключается в том, что сервисы взаимодействуют друг с другом для достижения общей цели. И нам нужно убедиться, что изменение кода не нарушит существующую функциональность. На самом деле достаточно убедиться, что изменение кода не повлияет на API сервиса. Если API сервиса не поврежден, то можно с уверенностью предположить, что потребительские микросервисы этого конкретного сервиса будут работать правильно. Так мы можем избежать запуска всего приложения для тестирования изменений в сервисе. Но каким способом будет проверяться целостность API сервиса? Ответ — с помощью тестирования контракта. Давайте рассмотрим простой пример, чтобы лучше это понять.
Читать далее