Contract-тестування мікросервісів

Проблема інтеграції мікросервісів

Коли десятки сервісів спілкуються один з одним по API, повноцінні end-to-end тести всієї системи стають повільними і крихкими: щоб протестувати один сценарій, потрібно підняти половину інфраструктури. При цьому зміна в одному сервісі може непомітно зламати іншого споживача його API, і про це дізнаються вже в продакшені. Детальніше про суміжний підхід можна прочитати в матеріалі «Тестування продуктивності: інструменти та метрики».

Як працює contract-тестування

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

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