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

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

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

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

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

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

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

Мысли?


person Karthik Balasubramanian    schedule 24.12.2018    source источник
comment
То, что вы описываете, зависит от производителя, а не от потребителя. Если производитель вносит критические изменения и контракт не обновляется, он не пройдет проверку.   -  person jonrsharpe    schedule 25.12.2018
comment
Меня беспокоит рабочий процесс: во всех примерах, которые я видел, производитель генерирует контракт, а потребитель просто выполняет свои тесты для этого файла jar. Если тесты терпят неудачу на стороне потребителя, ожидается ли, что команда потребителей поговорит с командой производителя и сообщит об ошибке? Мне это не кажется ориентированным на потребителя.   -  person Karthik Balasubramanian    schedule 25.12.2018
comment
Почему может показаться, что это ориентировано на потребителя? Это не; как вы говорите, производитель составляет контракт, а производитель просто проверяется на соответствие ему.   -  person jonrsharpe    schedule 25.12.2018
comment
Но разве весенний облачный контракт не должен способствовать тестированию Consumer Driven Contract? Одним из основных преимуществ CDC является информирование производителей с помощью автоматизированных тестов о внесении критических изменений. Возложение этой ответственности на каждого потребителя, чтобы убедиться, что они совместимы с производителем, похоже, противоречит CDC (очень хороший шанс, я мог ошибиться в CDC, и в этом случае, пожалуйста, поправьте меня)   -  person Karthik Balasubramanian    schedule 25.12.2018


Ответы (1)


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

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

Со стороны потребителя:

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

Со стороны производителя:

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

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

person Aleksandr Erokhin    schedule 28.12.2018
comment
Для меня это имеет смысл, но, на мой взгляд, это не масштабируемый подход. Как потребитель многих сервисов, я не могу ожидать клонирования исходного кода, принадлежащего другой команде, у меня будет возможность создавать и добавлять к нему контрактные тесты. Кажется, что на потребителя возлагается слишком большая ответственность. Мысли? - person Karthik Balasubramanian; 29.12.2018
comment
Что ж, каждый подход имеет смысл только в определенных ситуациях - здесь нет серебряных пуль. Если вы оцениваете CDC и видите, что он вам не подходит - вам следует либо адаптировать его под свои нужды, либо проверить другой. - person Aleksandr Erokhin; 29.12.2018
comment
Вы также можете хранить контракты во внешнем репо, где хранятся все контакты. - person Marcin Grzejszczak; 22.01.2019