Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В третьей части этой серии статей мы разобрались, как создавать тесты контрактов, ориентированных на потребителя, для наших потребителей Customer и Order и провайдера Address, с целью выявить потенциальные проблемы интеграции. Процесс генерации и распределения контрактов на стороне потребителя, а также получения и верификации их на стороне провайдера, все еще содержит приличное количество шагов, выполняемых вручную. Что еще хуже, у нас нет способа закрыть петлю обратной связи – мы никак не можем сообщить всем заинтересованным сторонам результаты верификации контракта провайдером.

В этой статье вы узнаете, как автоматизировать различные шаги в потоке тестирования контрактов, ориентированных на потребителя, и сможете добавить эти тесты в свои автоматизированные наборы.

Шаг 1. Запуск потребительских тестов из командной строки

Первый (небольшой, но важный) шаг – это добавление возможности запуска тестов на стороне потребителя из командной строки – именно этим способом инструменты непрерывной интеграции (Jenkins, GitLab, Azure DevOps) запускают тесты. В приведенных ниже примерах мы сделаем это, запуская тесты через Maven

mvn clean test

как команду командной строки. Мы получим вот такой результат (пример приведен для потребительского проекта заказчика):

...

[INFO] Results:
[INFO]
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  19.971 s
[INFO] Finished at: 2021-07-03T08:02:07+02:00
[INFO] ------------------------------------------------------------------------

При запуске тестов со стороны потребителя самая поздняя версия контракта, созданного в прошлый раз, будет записана в папку /target/pacts.

Шаг 2: Публикация сгенерированных контрактов

В предыдущей статье распределение контрактов между потребителем и провайдером выполнялось через физическое копирование сгенерированных контрактов и их размещение в правильной папке базы кода провайдера. Нет нужды говорить, что этот способ крайне ненадежен и вообще не масштабируется. Нам нужен механизм получше!

Встречаем Pact Broker. По сути это репозиторий контрактов, который позволяет:

• Потребителям – загружать свои контракты после их создания
• Провайдерам – забирать контракты на верификацию
• Провайдерам – загружать результаты верификации.

Pact Broker также поддерживает версионирование контрактов – он может хранить разные версии контрактов для каждой пары провайдер-потребитель. Документацию к Pact Broker можно найти здесь.

Прежде чем разобраться в автоматической публикации потребительских контрактов в Pact Broker, нужно знать, что для хостинга Broker есть два варианта:

• Самостоятельный хостинг: Broker доступен как образ Docker.
• Сервис: команда Pact предлагает также инструмент Pactflow – облачный вариант Pact Broker, у которого есть ряд функций, отсутствующих в Docker-версии.

Начистоту: Pactflow – это коммерческое приложение (с вариантом бесплатного плана). У меня, однако, нет никакого финансового интереса рекомендовать Pactflow в качестве решения. Причина, по которой я демонстрирую его на изображениях в статье – простота его локальной настройки. Все, что вы тут видите, можно сделать при помощи бесплатной Docker-версии Pact Broker.

Для публикации сгенерированного контракта в Pactflow Pact Broker я использую плагин Pact Maven со следующими настройками:

<plugin>
     <groupId>au.com.dius</groupId>
     <artifactId>pact-jvm-provider-maven</artifactId>
    <version>4.0.10</version>
    <configuration>
          <pactBrokerUrl>https://ota.pact.dius.com.au</pactBrokerUrl>
         <pactBrokerToken>YOUR_PACT_BROKER_TOKEN_GOES_HERE</pactBrokerToken>
         <pactBrokerAuthenticationScheme>Bearer</pactBrokerAuthenticationScheme>
     </configuration>
</plugin>

Примечание: 'provider' в имени плагина – это не опечатка. Этот плагин изначально был разработан для использования на стороне провайдера, а затем расширен, чтобы использоваться и на стороне потребителя. Команда Pact предпочла этот вариант разработке и поддержке двух разных плагинов.

После добавления плагина в проект мы можем опубликовать сгенерированные на предыдущем шаге контракты, используя

mvn pact:publish

После того, как мы проделали это для обоих потребителей, мы увидим два новых загруженных в Broker контракта. Оба они еще, очевидно, не верифицированы.

Что, если я не пользуюсь Maven (или Java)?

В этом примере Maven используется для запуска тестов и публикации сгенерированных контрактов в Pact Broker. Если вы не пользуетесь Java, то у Pact есть различные биндинги для распространенных языков, а также инструменты командной строки (CLI), позволяющие загружать (и получать) контракты в Pact Broker. Узнать о них больше можно здесь.

Шаг 3: Верификация контракта на стороне провайдера

В примере из предыдущей статьи мы задавали локальную папку, в которой провайдер может найти необходимые контракты, используя аннотацию @PactFolder. Если вы пользуетесь Pact Broker (и следовало бы), вместо этого можно использовать аннотацию @PactBroker:

@PactBroker(url = "https://ota.pact.dius.com.au", authentication = @PactBrokerAuth(token = "YOUR_PACT_BROKER_TOKEN_GOES_HERE"))

Прежде чем запускать верификационные тесты провайдера, Pact получит соответствующие контракты от брокера, используя ссылку и токен аутентификации, которые вы задали. Запуск

mvn clean test

для провайдера Address вернет следующий результат:

[INFO] Results:
[INFO]
[INFO] Tests run: 10, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  23.637 s
[INFO] Finished at: 2021-07-05T17:36:00+02:00
[INFO] ------------------------------------------------------------------------

Шаг 4: Загрузка результатов верификации провайдером

После успешной верификации, что реализация провайдера соответствует ожиданиям, выраженным в потребительском контракте, нам нужно уведомить потребителей об этом успехе, загрузив результаты верификации в Pact Broker.

Наиболее простой способ это сделать – это установка флага pact.verifier.publishResults на истину при прогоне тестов:

mvn clean -Dpact.verifier.publishResults=true test

В этом случае результаты верификации автоматически загрузятся в Pact Broker, указанный в аннотации @Pact Broker. В нашем примере мы увидим вот что:

Вы также можете использовать инструменты командной строки Pact для загрузки результатов верификации.

Шаг 5: Можно деплоить?

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

Чтобы помочь вам с ответом на этот вопрос, Pact Broker поддерживает матрицу совместимых пар провайдер-потребитель, а также окружений их деплоя. К тому же инструменты Pact Broker CLI включают can-i-deploy, проверяющий матрицу и дающий знать, совместима ли ваша текущая версия с прод-версиями сторон, с которыми у вас есть контракт.

Очевидный вопрос, который у вас, возможно, возник по поводу can-i-deploy:

Когда вызывать эту команду?

Хотя большая часть ответа на этот вопрос – это "зависит от контекста", стоит отметить, что тесты Pact обычно запускаются как часть локальных юнит-тестов и CI-процесса (как и прочие юнит-тесты). Запуск can-i-deploy обычно осуществляется в ходе CI/CD (в CI – чтобы знать, безопасно ли будет слияние, а в CD – чтобы помочь с безопасным выпуском новых версий в целевом окружении).

Примечание: чтобы успешно использовать can-i-deploy, стоит использовать тэги для идентификации версий, находящихся в проде (или пре-проде, или…). Документация can-i-deploy содержит полезные примеры тегов.

К тому же надо сказать, что команда Pact сейчас работает над функциями, упрощающими деплой через моделирование веток, окружений и тегов в качестве полноправных жителей Pact Broker. Идея тут в том, что их моделирование позволяет получать значения по умолчанию (к примеру, важные ветки и окружения) и предоставлять внятные значения по умолчанию в большинстве случаев, а не требовать, чтобы пользователи разбирались во всех клавишах и рукоятках, и наилучшем их сочетании. Больше информации об этом можно найти здесь.

Итак, все в порядке, да?

Вот и все! Мы успешно сделали исходные тесты контрактов на стороне как потребителя, так и пользователя, частью пайплайнов билда. Все проверки пройдены, и у нас все хорошо. Время расслабиться, да?

Ну… пока да. Как всем известно, ПО постоянно развивается, и совместимое сейчас может перестать таким быть потом! В следующей статье мы рассмотрим, что будет при изменении ожиданий потребителя, то, как Pact информирует нас о них, и что делать, чтобы разобраться с последствиями таких изменений.

Обсудить в форуме