🩻 Рентген співбесіди: "Бекенду ще немає, але треба тестувати"Питання від ліда:"Фронтендери (наприклад, на вашому улюбленому 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 з моками і молимось, щоб бекенд нічого не змінив.🤯 — Стоп, тобто фронтенд може диктувати бекенду, які дані повертати?!