English for Pact Contract Testing

Pact — це фреймворк для тестування контрактів, який допомагає командам, що працюють з мікросервісами або розподіленими системами, перевірити, що їхні сервіси можуть правильно спілкуватися без необхідності повного інтеграційного середовища. Якщо ви представляєте Pact своїй команді або обговорюєте його англійською мовою, правильний словник зробить ваші пояснення точним і переконливим.

Ключовий словник

Потребитель У рамках Пакту, споживач є службою, яка ініціює запит і залежить від відповіді. Споживач визначає, що йому потрібно від постачальника у формі договору. Приклад: “Фронт-енд програма є споживачем в цьому відношенні - вона викликає продуктову службу і очікує певної структури відповіді.”

Провайдер Постачальник — це служба, яка отримує запити і виконує їх. Робота провайдера полягає в тому, щоб перевірити, що він може виконувати всі контракти, визначені його споживачами. Приклад: «Продукт-сервіс є постачальником — йому потрібно перевірити, що він задовольняє всім контрактам, опублікованим його споживачами.»

Файл пакту Файл пакту є документом JSON, створеним під час тестування споживача, який описує взаємодії — запити, які споживач зробить, і відповіді, які він очікує. Цей файл буде спільно використано з постачальником послуг, зазвичай за допомогою Pact Broker.

• Приклад: « Під час тестування користувачами створюється файл пакту, який автоматично публікується у Pact Broker після кожного успішного збирання. » *

Договорный брокер Брокер пактів є центральним сховищем для зберігання і спільного використання файлів пактів між командами споживачів і постачальників. Він також відстежує результати перевірки і надає видимість, в які інтеграції безпечно розгортати.

• Приклад: « Ви можете перевірити у брокера пактів, чи перевірив провайдер найновішу версію нашого пакту. » *

** Можна розгорнути? ** «Чи можу я розгорнути?» є як концептуальним питанням, так і буквальною командою в екосистемі Пакту. За допомогою цього пункту можна перевірити, чи безпечно розгортати певну версію служби, враховуючи поточний стан перевірок у програмі Pact Broker. Приклад: “Запустити перевірку can-i-deploy перед випуском до виробництва — вона повідомить вам, чи всі ваші договори споживачів були перевірені.”

Поширені сценарії, де використовується ця мова

** При запрошенні на тестування контракту до вашої команди: ** Введення нової практики тестування вимагає чіткого пояснення її цінності. « Зараз ми покладаємося на спільне інтеграційне середовище для перевірки того, що наші служби працюють разом. Це середовище часто недоступне і його оновлення займе багато часу. Контрактне тестування з Pact дозволить нам перевірити інтеграції в наших CI-конвейерах без спільної інфраструктури»

В обзоре кода: Під час перегляду тестів користувачів ви можете зауважити: « Це визначення взаємодії виглядає правильно, але чи не могли б ви також додати тестовий випадок для відповіді на помилку? Провайдер повинен бути перевірений як на успіх, так і на невдачу.»

** Коли перевірка постачальника завершується невдало: ** “Перевірка постачальника зазнає невдачі при взаємодії GET /products/{id}. Споживач очікує поля category у відповіді, але наша поточна реалізація не повертає його. Нам потрібно або оновити постачальника, або обговорити новий контракт з командою споживачів»

Докладніше: Контракт Контракт — договір про виконання робіт

• «Ми визначаємо договір на стороні споживача, а провайдер перевіряє його незалежно»
• «Контрактне тестування замінює потребу в спільному інтеграційному середовищі в більшості випадків»
• «Файл пакту генерується автоматично, коли тести споживачів пройдуть.»
• «Ми публікуємо файли пакту до брокера пакту, щоб провайдери могли їх підібрати»
• «Перевірка провайдера виконується як частина CI-конвейера на кожному запиті на витягування»
• «can-i-deploy перевірка є нашим воротами перед будь-яким розгортанням до виробництва.»
• Якщо провайдер змінить поле відповіді, ми негайно впізнаємо його в тестах споживачів
• «Це підхід, орієнтований на споживача — споживач визначає, що йому потрібно, і постачальник повинен задовольнити це»
• «Ми використовуємо функцію затримки договорів, щоб дозволити споживачам додавати нові взаємодії без негайного розбиття побудови провайдера»
• «The Pact Broker показує діаграму мережі, в якій послуги залежать одна від одної»

Використовується для перевірки нестандартних технічних рішень

Контрактне тестування може бути важко пояснити людям поза інженерією. Використовуйте аналогію: «Уявіть, що дві компанії погоджуються на офіційний контракт перед початком спільної роботи. Тестування контрактів є тією ж ідеєю, що застосовується до програмних послуг. Кожна команда обслуговування визначає, що вони обіцяють доставити, і автоматизовані тести перевіряють, що обіцянки дотримуються. ”

Сфокусуйтеся на бізнес-вигодах: «Контрактне тестування ловить інтеграційні помилки набагато раніше в циклі розробки, зменшуючи кількість проблем, які досягають виробництва і вартість їх виправлення»

Практичні рекомендації

Напишіть коротке пояснення (150- 200 слів) щодо того, як працює тестування контрактів Pact, так, ніби ви пояснювали це новому розробнику сервера, який приєднався до вашої команди і ніколи не чув про цей інструмент. Використовуйте принаймні чотири з цих слів. Сфокусуйтеся на ясності — припустимо, що читач розуміє мікросервіси, але не має попередніх знань про тестування контрактів.

Навигація Nuance: контракт тестування словниковий запас для не-рідних мовців

Тестування договорів Pact може здатися простим — визначте своїх споживачів, визначте своїх постачальників, і дозвольте Pact обробляти синхронізацію. Але ефективне спілкування навколо цього підходу сильно залежить від точного англійського словника і розуміння спільної фрази. Це не просто про роблення тестів; це про вираження їхньої мети, пояснення їх переваг і вирішення розбіжностей в команді розробників. Критичним елементом, який часто ігнорується, є тонкі нюанси професійної англійської, особливо щодо технічних обговорень і зворотного зв’язку. Наприклад, простого зауваження «контракт не збігається» недостатньо. Вам потрібно передати * чому * це не збігається і які кроки потрібно зробити.

Одна з найпоширеніших проблем для носіїв мови, які не є рідними, виникає при описі змін до контрактів. У типовому коментарі перегляду коду може бути написано: « Ця зміна вводить API, який порушує правила ». Хоча ця фраза технічно правильна, вона може сприйматися як конфронтація. Більш конструктивним підходом буде: «Це оновлення змінює поле User об’єкта id, що вимагає, щоб споживачі, що використовують це поле, були відповідно оновлені. Чи можемо ми обговорити потенційний вплив на залежні послуги?» Зауважте зміну: вона зосереджена на впливі, а не просто на позначці зміни як «пошкодження». Аналогічно, у обговореннях Slack, замість того, щоб сказати «Pact не працює», спробуйте «Я стикаюся з проблемами з синхронізацією Pact; Я бачу розбіжності між моделями провайдера і споживача». Останнє підкреслює конкретну проблему і запрошує до співпраці.

Іншою частою областю для плутанини є заклик до тестування контрактів. Пояснюючи його цінність зацікавленим сторонам, уникайте надмірно технічного жаргону. Замість того, щоб сказати «ми повинні реалізувати взаємну адаптацію», ви могли б пояснити: «Використовуючи Pact, ми активно вирівнюємо наші команди споживачів і постачальників, мінімізуючи проблеми інтеграції пізніше в життєвому циклі розробки, і зменшуючи дорогі переробки». Створення його навколо зменшення ризику і ефективності звучить набагато краще, ніж чисто технічні описи. Пам’ ятайте, що ваша мета — продемонструвати чітку перевагу — скорочення часу розробки, менше помилок і збільшення співпраці команди. Сфокусуйтесь на результатах, а не на процесах.

Нарешті, зверніть увагу на формулювання навколишніх розбіжностей. Замість того, щоб сказати «Ви помиляєтеся», спробуйте «Я розумію вашу точку зору, але я вірю, що цей підхід представляє інший набір викликів, пов’язаних з [конкретною проблемою]. Давайте розглянемо, як ми можемо примирити ці відмінності. » Це демонструє повагу до думки іншої людини, одночасно відстоюючи свою позицію.

Ось приклад використання CLI pact-consumer Pact для ілюстрації перевірки контракту:

pact-consumer --provider-url http://localhost:5678/api/users --consumer-base-uri http://localhost:3000/api/users  --sync-mode all --validate

За допомогою цієї команди можна продемонструвати основні налаштування споживача Pact, синхронізацію з постачальником послуг, а потім перевірку договору. Прапорець --validate є ключовим - це не просто запуск тестів; це активне підтвердження того, що очікування контракту виконуються провайдером. Ця дія надає конкретні докази для обговорення невідповідностей у контракті.