Home

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

Недавно я начал работать над новым консалтинговым проектом с клиентом из Великобритании. Я помогаю ему внедрить тестирование контрактов, чтобы лучше понимать, как изменения, вносимые отдельными командами в отдельные сервисы, влияют на ситуацию выше и ниже по течению в распределенном окружении.

Большинство людей, думая или говоря о тестировании контрактов, думают об ориентированном на потребителя варианте, который часто сокращают, как CDCT. Однако тестирование контрактов куда шире «только» CDCT. Одним из первых вопросов, на которые надо найти ответ, и про который часто забывают, будет вопрос «Какой тип тестирования контрактов лучше всего подойдет нашей ситуации?»

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

Ориентированное на потребителя тестирование контрактов (CDCT)

Как можно предположить из названия, в CDCT музыку, так сказать, заказывает потребитель. Потребитель описывает свои ожидания от поведения поставщика в контракте, а затем передает контракт поставщику. Затем это обязанность поставщика – продемонстрировать, что он способен соответствовать всем ожиданиям потребителя.

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

Простой пример: потребитель А ожидает, что поставщик вернет номер дома, как строку, а поставщик Б ожидает, что тот же поставщик вернет его, как число. Именно такие виды потенциальных проблем интеграции и вскрывает тестирование контрактов, и они часто проскакивают незамеченными при более традиционном интеграционном тестировании. Ну или при его отсутствии…

Вот так выглядит типичная ситуация при CDCT:

Опишу словами:

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

2. Поставщик забирает релевантные контракты из хранилища и верифицирует, может ли он выполнить все ожидания во всех контрактах.

3. Поставщик публикует результаты верификации в хранилище.

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

CDCT особенно полезно в ситуациях, когда

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

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

CDCT не особенно вам пригодится, если:

• Поставщик – публичный API, то есть поддерживать связь отдельных команд потребителей с его командой разработки трудно или невозможно.
• Поставщик не склонен внедрять тестирование контрактов и/или прислушиваться к нуждам отдельных потребителей и подстраиваться под них (тут публичные API – тоже хороший пример).

Другие ситуации, для которых CDCT не годится, описаны здесь.

Ориентированное на поставщика тестирование контрактов (PDCT)

Как вы, вероятно, догадались по названию, в PDCT главенствует поставщик, а не потребитель. По сути поставщик выпускает контракт, описывающий его поведение и сообщающий потребителям «Оно работает вот так, а дальше не мои проблемы». Типичная PDCT-ситуация, соответственно, куда прямолинейнее CDCT:

Опишу словами:

1. Поставщик выпускает контракт, описывающий его поведение.

2. Потребители используют выпущенные поставщиками контракты, чтобы разобраться, смогут ли они общаться с поставщиком.

Я считаю, что наибольший недостаток PDCT – это отсутствие петли обратной связи – у потребителя нет возможности сообщить поставщику «это работает, а это нет». Инициатива и власть полностью в руках поставщика, потребитель никак не может выразить свои опасения и переживания, неважно, связаны они с поведением поставщика или его архитектурой.

Итак, минусом PDCT будет отсутствие обратной связи, а самый большой недостаток CDCT – усилия, необходимые для хорошей реализации и поддержки. Поэтому недавно возник третий тип тестирования контрактов.

Двустороннее тестирование контрактов (BDCT)

В BDCT главными не будут ни поставщик, ни потребитель. Вместо этого и поставщик, и потребитель создают каждый свою версию контракта для конкретной интеграции – контракт потребителя (как и в CDCT) содержит его ожидания от поведения поставщика, а контракт поставщика (как в PDCT) – спецификацию его поведения.

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

Вот так это выглядит:

Опишу словами:

1. И поставщик, и потребитель загружают свои контракты в хранилище контрактов.

2. Хранилище (которое теперь участвует в верификации) сравнивает контракты и проверяет на наличие потенциальных проблем интеграции.

3. И потребитель, и поставщик могут запросить у хранилища позднейшие результаты верификации, чтобы не пропустить потенциальные интеграционные проблемы и понять, безопасно ли заливать новый билд на прод.

На данный момент единственный способ реализации BDCT, известный мне – это Pactflow. Если вы хотите увидеть рабочий пример BDCT, то вот пример, созданный и описанный мной.

Наибольшее преимущество BDCT в то, что его внедрение через Pactflow и общую экосистему Pact означает, что вы можете опираться на существующую технологию для более быстрой генерации контрактов, не завися от полноценного внедрения Pact.

Для некоторых команд и компаний недостатком может стать необходимость использования Pactflow (облака или локальной установки).

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

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