Меню

Вступ до контрактного тестування на прикладах

introduction contract testing with examples

Спробуйте Наш Інструмент Для Усунення Проблем

сортування за міхуром за спаданням c ++

Цей підручник з контрактного тестування пояснює, що таке споживче контрактне тестування, як воно працює та чому ви повинні використовувати його у своїй стратегії тестування:

Що таке контрактне тестування?

Контрольне споживче тестування - це форма тестування API, яка справді дає змогу рухатися вліво. Інструментом контракту, який ми використовуємо, є Pact.io , і ми дізнаємось про це пізніше у цій серії навчальних посібників.

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

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

Контрактне тестування

Що ви дізнаєтесь:

Перелік навчальних посібників у цій серії контрактних випробувань

Підручник No1: Вступ до контрактного тестування на прикладах (Цей підручник)
Підручник No2: Як написати тест споживчого пакту в JavaScript
Підручник No3: Як опублікувати договір договору для брокера
Підручник No4: Перевірте договір договору та безперервне розгортання за допомогою Pact CLI

Контрольне споживче випробування

Початковою точкою є ваша документація API, яка формує контракт на тестування. На даний момент, як правило, команди розробників беруть документ API і розробляють його відповідно до документа wiki (або будь-якого формату, який він знаходиться у вашій організації, наприклад, Word Document).

Наприклад, веб-додаток, де інтерфейс розробляє Team Krypton, а API розробляє Team Thoron. Проект починається з початкової зустрічі, де вимоги представлені та узгоджені між командами.

Кожна команда приймає вимоги і починає створювати відставання, допрацьовуючи історії. Розробка починається в обох командах за історіями користувачів, тестування інтеграції залишається для подальших спринтів. Оскільки команда Krypton знаходить додаткові вимоги щодо сценаріїв помилок, документація API відповідно оновлюється.

Team Thoron додає тестові кейси, пов’язані з оновленими сценаріями на основі документації.

Уже ми можемо побачити кілька недоліків у цьому процесі, і я додав ще пару для успіху:

  1. Зміни документа API можуть не передаватися ефективно.
  2. Фронт-енд-команда заглушує сервіс-сервер і навпаки.
  3. Back-end команда створює тестові приклади інтеграції на основі документації.
  4. Інтеграційне середовище - це перший раз, коли перевіряється повна інтеграція.
  5. Різна версія API щодо середовища інтеграції проти виробництва.

Споживче контрактне тестування має дві сторони, тобто споживача та постачальника. Тут традиційне мислення про тестування в мікросервісах перевертається.

Споживач є куратором сценаріїв, включаючи запит та очікувану відповідь. Це дозволяє вам стежити Закон Ліжка що диктує, що ви повинні бути гнучкими в тому, що може прийняти ваш API, але консервативними в тому, що надсилається. Повертаючись до недоліків №. 1, 3 і 4, зміни в документації здійснюються споживачем.

Наприклад, в тому випадку, коли Team Thoron змінює рядкове поле, щоб не приймати нульові значення, споживчі тести не відображатимуть зміни і, отже, не зможуть. Або принаймні до тих пір, поки зміни в команді Криптон не будуть внесені.

Визначте споживчі очікування

(зображення джерело )

Постачальник перевіряє сценарії, що надаються споживачем, щодо їхнього «розробницького» середовища. Це дозволяє вашим мікросервісам застосовувати Паралельна зміна де зазначено, що вам слід розширити функціональність API, а потім перейти на нову версію. Посилаючись на недолік №. 2, заглушки, які зазвичай створюють команди заднього плану для власних вимог до тестування, тепер можуть базуватися на споживчих сценаріях з використанням Сервер Pact Stub .

Перевірте очікування щодо постачальника

Обов’язковим елементом обох сторін є „контракт”, який необхідно ділити між командами. Пакт забезпечує платформу для спільного використання контрактів під назвою Брокер пактів (доступна як керована послуга з Pactflow.io ).

Брокер зберігає результати споживчих сценаріїв. Потім контракт зберігається у брокера поряд з версією API. Це дозволяє тестувати кілька версій API, отже, сумісність може бути підтверджена до випуску, як це зазначено у ваді 5.

pact_network_diagram
Брокер пактів - візуальне представлення

Додатковою перевагою Pact Broker на застарілих платформах є видимість споживачів. Не всі споживачі були відомі авторам API, особливо це не те, як воно споживається.

Зокрема, посилаючись на випадок, коли підтримувалися дві версії API, у версії 1 (V1) виникла проблема з даними, через яку API викликав брудні дані в базі даних.

Зміна була впроваджена у V1 API та спрямована на виробництво, однак споживач покладався на формат, який спричиняв проблему з даними, тим самим порушуючи їхню інтеграцію з API.

Як це працює

Потік автентифікації

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

Тест Consumer створює запит POST для маркера, передаючи тіло з іменем користувача та паролем.

Запит POST

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

макет сервера

Результат споживчого тесту генерує файл договору про пакт. Це буде збережено у брокері пактів як версія 1.

Потім постачальник витягує версію 1 у брокера договорів і повторно відтворює цей запит у своєму локальному середовищі, перевіряючи відповідність запиту та відповіді вимогам споживача.

пакт-брокер

Ролі та обов'язки

Ролі та обов

Забезпечення якості (QA) / тестер: Створення контрактів за допомогою Pact.io та робота з BA для створення тестових сценаріїв.

Розробник: Поєднання з QA щодо створення тестів та сприяння обгортанню API для впровадження в безперервну інтеграцію (CI).

Бізнес-аналітик (BA): Створення сценаріїв та робота з архітектором для перевірки постраждалих сторін.

Архітектор рішень (Можливо, у вашій організації не існує): Застосування змін API та узгодження з BA щодо впровадження, а також інформування про зміни споживачів (за допомогою Pact Broker, щоб зрозуміти, кого це може стосуватися).

Управління випусками: (Так, я знаю, що це старомодно, але все ще існує у моєму світі): сповнений впевненості, що зміни будуть успішно опубліковані завдяки охопленню контрактом.

Вся команда: Перевірте результати, щоб визначити, чи можна випускати версії до виробництва за допомогою інструменту Pact CLI, Чи можу я розгорнути .

Контрактне тестування проти інтеграційного тестування

Інтеграційне тестування має існувати для того, щоб перевірити, чи працює система до просування у виробниче середовище, але сценарії можна значно зменшити.

Вплив цього може бути:

  • Швидший відгук перед виходом в середовище інтеграції.
  • Менша залежність від стабільності інтеграційного середовища.
  • Менше середовищ, що підтримують кілька версій API.
  • Скорочено нестабільні випадки оточення через проблеми інтеграції.
ІнтеграціяДоговір
Очевидно, точно визначити невдачуБагато шарівДуже легко
Налаштування APIТакНе
Перевірка розгортанняТакНе
Версія APIТакТак
Налагодження локальноНеТак
Екологічні проблемиТакНе
Час зворотного зв’язкуПовільноШвидко

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

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

Тому ви хочете запускати основні сценарії тестування, які підтверджують конфігурацію, наприклад, кінцева точка перевірки стану для версії API. Також доводить, чи розгортання було успішним, повертаючи відповідь 200.

Під час тестування за контрактом ви перевіряєте специфіку API, що включає крайні випадки, пов’язані зі структурою API, вмістом (наприклад, значення полів, ключі існують) та відповідями на помилки. Наприклад, чи API обробляє нульові значення, або вони вилучені з відповіді API (інший реальний приклад).

Деякі переваги (якщо ви ще не продані)

Нижче наведено деякі переваги, якими можна скористатися під час продажу контрактного тестування для більш широкого бізнесу:

  • Швидше розгортання програмного забезпечення
  • Єдине джерело істини
  • Видимість усіх споживачів
  • Простота тестування на різні версії API.

Часті запитання

Деякі найпоширеніші запитання, коли намагаються переконати людей прийняти контрактне тестування, включають:

Q # 1) Ми вже маємо 100% охоплення тестом, тому нам це не потрібно.

Відповідь: Ну, це неможливо, але контрактне тестування має багато інших переваг, ніж просто охоплення тестуванням.

Питання 2) Відповідальність архітектора рішень - повідомляти про зміни API.

Відповідь: За якість відповідає вся команда.

Запитання №3) Чому ми створюємо тестові сценарії для команди API?

Відповідь: Команда API не знає, як працює веб-служба, тож чому вона несе відповідальність.

Q # 4) Наші наскрізні тести охоплюють весь потік від початку до кінця, включаючи інші точки інтеграції.

Відповідь: Саме тому ми розділяємо тести, щоб перевірити одне, і ви не несете відповідальність за тестування наскрізного потоку системи, яка ви не знаєте, як вона працює.

Q # 5) У сховищі якої команди живуть тести?

Відповідь: І те, і інше. Споживач у своєму сховищі та Постачальник у своєму. Тоді в центральній точці контракт живе за межами будь-якого з них.

Аргументи

тип тестування в програмній інженерії

Ось аргументи, проти яких нам важко сперечатися, коли йдеться про перехід на контракт для тестування:

  • Документація Swagger вже на місці, яка може бути використана для створення інтеграційних тестів.
  • Команди володіють як інтерфейсними, так і сервісними службами з ефективним механізмом змін API.

Постійна інтеграція

Як це вписується у ваш пакет тестування на безперервну інтеграцію? Бажане місце для контрактного тестування - це тести з вашими модулями.

Споживчі тести закручують макетний сервер, який не вимагає зовнішніх залежностей поза тестом.

Тести постачальників вимагають екземпляра API, тому локальний API можна обернути за допомогою тестовий сервер в пам'яті . Однак, якщо нелегко обернути ваш API локально, обхідним шляхом, який ми використовували раніше, є те, що ми закрутили середовище та розгортаємо код у цьому середовищі як частину автоматичних перевірок запиту на витягування.

Постійна інтеграція

Постійна інтеграція відео

Постійна інтеграція 3

(зображення джерело )

Висновок

У цьому підручнику ми дізналися, що означає контрактне тестування і як воно виглядає в мікросервісній інфраструктурі, і побачили, як воно виглядає на реальному прикладі.

Вивчили уроки про те, як тестування за контрактом може допомогти вам перенести ваше інтеграційне тестування вліво. Крім того, ми побачили, як це може зменшити витрати для вашої організації за рахунок скорочення часу зворотного зв’язку, пов’язаного з проблемами інтеграції.

Контрактне тестування - це не лише інструмент технічного тестування, воно забезпечує співпрацю команд розробників, повідомляючи зміни та заохочуючи тестування як єдине ціле. Загалом, це має бути обов’язковою умовою для тих, хто хоче перейти до Постійного розгортання.

НАСТУПНИЙ підручник

Рекомендована література