Концептуальные вопросы относительно использования пакта

Question

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

1. Вопрос: При реализации тестов провайдера, при чем "слой "приложения мы должны реализовать наши тесты в? Справочная информация: Когда мы впервые начали добавлять тесты CDC с pact в наши приложения, мы провели функциональное тестирование, запустив контекст приложения, включая базу данных в памяти, и настроили данные в этой базе данных.Это привело к тому, что тесты было трудно поддерживать, кроме того, мы фактически проводили функциональное тестирование, а договор не предназначен для этого.После продуманного подхода к тому, как мы хотим реализовать тесты несколько раз, мы закончили тем, что просто протестировали нашу границу, которая включает интерфейс отдыха и (в лучшем случае) проверку ввода и вывода.
2. Вопрос: Какова идея использования нескольких состояний провайдера? Справочная информация: Pact поддерживает использование нескольких состояний провайдера для одного взаимодействия.Мы экспериментировали с этой функцией, но многие наши разработчики не считают, что в нескольких государствах-провайдерах есть большое преимущество.Поэтому многие из наших тестов cdc с pact имеют длинные и сложные описанные состояния провайдеров.Поэтому я думаю, что мы не поняли основную концепцию этой функции.
3. Вопрос: В чем заключается идея параметризованных состояний провайдера? Фон: В основном тот же фон, что и раньше.Мы экспериментировали с этой функцией, но многие наши разработчики решили ее не использовать.Поскольку отказ от этой функции основан на неполном понимании этой функции, я хотел бы знать, для чего предполагается использовать эту функцию.
4. Вопрос: Как нам следует справляться с пактом относительнонаша стратегия управления версиями? Справочная информация: В настоящее время обработка контрактов между приложениями с семантической версией задокументирована в официальной документации pact .Мы используем управление версиями SNAPSHOT, и изменение стратегии управления версиями в настоящее время невозможно.Кроме того, в нашей компании существует множество других команд, которые имеют разные стратегии управления версиями.В принципе, невозможно согласовать одну стратегию в целом.Что это значит, когда мы говорим об использовании cdc с pact во всей нашей компании?К каким проблемам это может привести?Правильно ли помечены контракты (основной, функциональный, разработка, производство и т. Д.), Чтобы решить любые проблемы, связанные с управлением версиями?

Answer 1

1. Pact не должен влиять на тесты вашего провайдера. Вы должны продолжать писать свои модульные тесты и функциональные интеграционные тесты (под интеграцией я подразумеваю тесты, которые обеспечивают правильную совместную работу различных компонентов службы).
   То, что добавляет Pact, является новым шагом в вашей сборке CI. Во время сборки вы должны использовать pact-provider-verifyier , который берет пакт, созданный потребителем, воспроизводит его для вашего провайдера и сравнивает фактический ответ с ожидаемым ответом, определенным в пакте. Это позволяет вам убедиться, что ваш провайдер может выполнять ожидаемые взаимодействия, определенные потребителем.

2. Я думаю, что основная идея нескольких состояний провайдеров - это повторное использование порядка и кода. Представьте, что ваш потребитель определяет 2 взаимодействия со следующими состояниями провайдера:

   • "Пользователь с идентификатором 123 существует, и у него есть одно сообщение"
   • «Пользователь с идентификатором 123 существует и принадлежит к группе администраторов»

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

   • «Пользователь с идентификатором 123 существует»
   • "Пользователь 123 имеет одно сообщение"
   • «Пользователь 123 принадлежит группе администраторов»

3. Если вы посмотрите на приведенный выше пример, вы увидите, что провайдер теперь очень связан с пользователем с идентификатором 123. Если потребитель решил изменить его на идентификатор 456, это нарушит настройку провайдера. реализация. Таким образом, идея состоит в том, чтобы передать «123» в качестве параметра, а не в строке описания состояния. Тогда договор будет выглядеть примерно так:

"providerStates": [{
  "name": "The user exists",
  "params": {"id" : 123}
}]

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

Answer 2

Во-первых, я хотел бы сказать, что это здорово, что вы берете на себя инициативу опробовать Pact для всей вашей компании:)

Мы пытаемся улучшить способ взаимодействия с Pact, понимая это.это не простая проблема, которую нужно решить или передать другим разработчикам.Будем весьма благодарны за любые предложения по улучшению документации / веб-сайта.

Теперь перейдем к вопросам:

При реализации тестов провайдера, на каком «уровне»В каком приложении мы должны реализовывать наши тесты по адресу?

Pact, по сути, пытается заменить / улучшить интеграционные тесты, или то, что некоторые считают функциональными тестами на стороне поставщика.Тем не менее, эта номенклатура не очень хорошо подходит для некоторых компаний / групп, поскольку некоторые используют «функциональные» тесты как означающие сквозные тесты через браузер.

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

Вопрос: ЧтоВ чем заключается идея использования нескольких состояний провайдеров?

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

Вопрос: Какова идея параметризованных состояний провайдера?

Параметрыэто быстрый и простой способ ввести некоторые переменные данные в состояние, например идентификатор, который может понадобиться взаимодействию, чтобы точно проверить, является ли идентификатор точно таким же, или вы также можете использовать его с несколькими состояниями для создания конкретной ситуации, например«создайте пользователя с идентификатором X», затем «отключите пользователя с идентификатором X».

Вопрос: Как мы должны обращаться с pact относительно нашей стратегии управления версиями?

Pact упоминает лучше всегометоды обработки версий, и это семантическое управление версиями;это всегда был отличный способ понять, обновляет ли пользователь свой код / ​​зависимости, исправляет ли это, добавление или что-то нарушает.

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

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

Ура,

M

Answer 3

В дополнение к тому, что ответил Саймон:

1. Если вы посмотрите на пирамиду тестирования, тесты pact находятся на грани между единичными и интегрированными тестами.Но если вы можете толкнуть их вниз в пространство устройства, они станут проще в обслуживании.Когда я пишу свои контактные тесты, я концентрируюсь на контакте, чтобы убедиться, что он больше не делает.
2. Саймон хорошо ответил на 2 и 3.Истинная причина нескольких состояний провайдеров - кто-то просил об этом.Я ими не пользуюсь, мне всегда достаточно одного.
3. Опять же, как ответил Саймон.Мы ввели параметры, потому что заметили, что между потребительскими и провайдерскими тестами существует связь между тестовыми даннымиДанные, которые использовал потребитель, должны были соответствовать данным в состоянии провайдера, поэтому ответ, который генерирует провайдер, будет релевантным для потребителя.Это делает для хрупких испытаний.Перед параметрами данные должны были быть закодированы в описание, чтобы разорвать связь.Я написал много методов состояния провайдера, которые использовали регулярные выражения в описании для извлечения данных.
4. Единственное требование - иметь уникальную версию для потребителя и провайдера.Они не должны использовать одну и ту же схему.Каждый опубликованный договор должен быть идентифицируемым, а также опубликованный результат проверки поставщика.Версии также должны быть последовательными, чтобы брокер мог отличить более старую версию от более новой.Семантическое версионирование подходит хорошо.Отметка времени также может работать здесь.Не так легко читать.