🩻 Рентген співбесіди: "Бекенду ще немає, але треба тестувати"Питання від ліда:

"Фронтендери (наприклад, на вашому улюбленому Angular) вже все зверстали. Але бекенд (на NestJS) ще навіть не починав писати API. У нас є тільки узгоджений Swagger-файл. Як QA гарантувати, що коли вони нарешті зійдуться на тестовому середовищі, все не вибухне?"❌ Відповідь рівня Junior (Хибний шлях):

"Я просто напишу моки (фейкові дані) для E2E-тестів у Playwright і буду тестувати фронтенд ізольовано. А коли бекенд буде готовий — проженемо реальні тести."Чому це провал: Ваші моки дуже швидко застаріють. Якщо через тиждень бекендер вирішить перейменувати поле userId на user_id, ваші фронтенд-тести залишаться зеленими (бо моки старі), а на продакшені все впаде.✅ Відповідь рівня Senior (Підхід Архітектора):

"Нам потрібне Contract Testing (Контрактне тестування), наприклад, через інструмент Pact."
Алгоритм:1️⃣ Фронтенд пише тест, який генерує "Контракт" (JSON -файл). У ньому чітко написано: "Я відправляю запит X і очікую отримати поле userId у форматі числа".2️⃣ Цей контракт автоматично завантажується в Pact Broker (спільний репозиторій).3️⃣ Коли бекендер пише свій код, його CI/CD пайплайн автоматично стягує цей контракт і перевіряє свій API проти нього.4️⃣ Якщо бекендер перейменував поле або змінив тип даних — його пайплайн падає ще до деплою.
Золоте правило: E2E -тести занадто повільні для перевірки інтеграції двох команд. Контрактні тести — це автоматизований "договір" між клієнтом і сервером, який не дозволяє їм зламати один одного. А як ви тестуєте розірвані команди?

👇🔥 — Pact — наш бро! Ловимо невідповідності ще в пайплайнах.

👀 — Пишемо E2E з моками і молимось, щоб бекенд нічого не змінив.

🤯 — Стоп, тобто фронтенд може диктувати бекенду, які дані повертати?!