Почему при использовании Spring Cloud Contracts производитель создает контракты? - PullRequest
Новая
       86

Почему при использовании Spring Cloud Contracts производитель создает контракты?

0 голосов
/ 25 декабря 2018

Я играл с Spring Cloud Contracts.Вот мое понимание рабочего процесса до сих пор.

На стороне сервера

  • Написать контракт (в groovy или yaml)
  • Автоматически генерировать тесты (используя плагин gradle)
  • НастройкаBaseClass, который выполняет соответствующие настройки установки для контроллера
  • Запустите автоматически сгенерированные тесты
  • Опубликуйте файл jar-заглушек, сгенерированный для локального репозитория (который содержит встроенный сервер Wiremock, с запросом / ответом))

На стороне клиента

  • Загрузить файл с заглушкой
  • Записать тесты для этой заглушки.Используйте stubrunner для проверки ответов

Что я не могу понять, так это как работает этот потребитель?Контракты, похоже, исходят от производителя, потребитель, похоже, пассивно проверяет то, что опубликовал производитель (используя файл заглушек).Производитель может случайно не обновлять контракты, но вносить критические изменения.Это может привести к прохождению тестов на клиенте, даже если он не прошел.Это правда или я неправильно понял шаг, когда контракты создаются со стороны потребителя

Мысли?

1 Ответ

0 голосов
/ 28 декабря 2018

Контракт, управляемый потребителем (CDC) Разработка - это, в основном, Разработка, управляемая тестом (TDD), распространяемая на приложения "производитель-потребитель".Так как это TDD - сначала должны быть тесты, а затем реализация.И так как он управляется потребителем - потребитель создает тесты для производителя .

Итак, давайте предположим, что у нас есть Производитель и Потребитель, а также несколько новых feature, которые необходимо реализовать.В CDC рабочий процесс будет выглядеть следующим образом (дополнительную информацию можно найти в официальной документации ).

На стороне потребителя:

  • Написать отсутствующую реализациюдля функции
  • клон источник хранилище локально
  • локально определить контракт в хранилище производитель (и автоматически сгенерировать для него модульные тесты)
  • Запустить интеграционные тесты (на стороне cosumer )
  • Подать запрос на получение

На стороне производителя:

  • Возьмите запрос на извлечение (тесты уже сгенерированы здесь cosumer )
  • Напишите отсутствующую реализацию (в стиле TDD)
  • Разверните свое приложение
  • Работа в сети

Теперь все это имеет смысл, поскольку потребитель пишет контракты для новой функции (но в репозитории производителя *1050*) - мыесть подход, ориентированный на потребителя .

...