Почему при использовании Spring Cloud Contracts производитель создает контракты?
Я играл с Spring Cloud Contracts. Вот мое понимание рабочего процесса на данный момент.
На стороне сервера
- Напишите договор (на Groovy или на ямле)
- Автоматическое создание тестов (с использованием плагина gradle)
- Setup BaseClass, который выполняет соответствующие настройки для контроллера
- Запустите автоматически сгенерированные тесты
- Опубликуйте созданный файл jar-заглушки в некотором локальном репо (который содержит встроенный сервер Wiremock с запросом / ответами)
На стороне клиента
- Загрузите файл-заглушку jar
- Напишите тесты для этой заглушки. Используйте stubrunner для проверки ответов
Я не могу понять, как движется этот Потребитель? Кажется, что контракты исходят от производителя, а потребитель, кажется, пассивно тестирует то, что опубликовал производитель (используя файл jar-заглушек). Продюсер мог случайно не обновить контракты, а внести критические изменения. Это может привести к прохождению тестов на клиенте, даже если он должен был дать сбой. Это правда, или я неправильно понял шаг, на котором контракты создаются со стороны потребителя?
Мысли?
Меня беспокоит рабочий процесс: во всех примерах, которые я видел, производитель генерирует контракт, а потребитель просто выполняет свои тесты для этого файла jar. Если тесты на стороне потребителя терпят неудачу, ожидается ли, что команда потребителей поговорит с командой производителей и сообщит об ошибке? Мне это не кажется ориентированным на потребителя.
Почему было бы кажутся ориентированными на потребителя? Это не; как вы говорите, производитель составляет контракт, а производитель просто проверяется на соответствие ему.
Но разве весенний облачный контракт не должен способствовать тестированию Контракт, ориентированный на потребителя? Одним из основных преимуществ CDC является информирование производителей с помощью автоматизированных тестов о внесении критических изменений. Возложение этой ответственности на каждого потребителя, чтобы убедиться, что они совместимы с производителем, похоже, противоречит CDC (очень хороший шанс, я мог ошибиться в CDC, и в этом случае, пожалуйста, поправьте меня)
Ответы 1
Контракт, ориентированный на потребителя (CDC) Разработка - это, по сути, Разработка через тестирование (TDD), расширенный до приложений "производитель-потребитель". Поскольку это TDD - сначала должны идти тесты, а затем реализация. И так как это Consumer Driven - потребитель создает тесты для производителя.
Итак, предположим, что у нас есть производитель и потребитель, а также новый feature, который необходимо реализовать. В CDC рабочий процесс будет выглядеть следующим образом (дополнительную информацию можно найти в официальная документация).
Со стороны потребителя:
- Напишите недостающую реализацию функции
- Клонировать репозиторий Режиссер локально
- Определите контракт локально в репозитории Режиссер (и автоматически сгенерируйте для него модульные тесты)
- Запустите интеграционные тесты (на стороне Cosumer's)
- Подать пул реквест
Со стороны производителя:
- Возьмите на себя пул-реквест (тесты уже созданы здесь покупатель)
- Напишите недостающую реализацию (в стиле TDD)
- Разверните свое приложение
- Работа онлайн
Теперь все имеет смысл, поскольку потребитель записывает контракты для новой функции (но в репозитории продюсерский) - у нас есть Подход, ориентированный на потребителя.
Для меня это имеет смысл, но, на мой взгляд, это не масштабируемый подход. Как потребитель многих услуг, я не могу ожидать клонирования исходного кода, принадлежащего другой команде, и у меня будет возможность создавать и добавлять к нему контрактные тесты. Кажется, что на потребителя возлагается слишком большая ответственность. Мысли?
Что ж, каждый подход имеет смысл только в определенных ситуациях - никаких «серебряных пуль». Если вы оцениваете CDC и видите, что он вам не подходит - вам следует либо адаптировать его под свои нужды, либо проверить другой.
Вы также можете хранить контракты во внешнем репо, где хранятся все контакты.
То, что вы описываете, зависит от производителя, а не от потребителя. Если производитель вносит критические изменения и контракт не обновляется, он не пройдет проверку.