Contract и component tests

Контрактные тесты фиксируют соглашения API между consumer и provider — форму запроса, коды, заголовки, схему — без поднятия всей системы. Компонентные тесты рендерят срез UI (секцию страницы или дерево виджетов) с реалистичными провайдерами и проверяют видимое пользователю поведение и стыковку с ближайшими детьми — между unit и E2E.

Они полезны, когда микросервисы или design system развиваются отдельно: контракты ловят breaking changes рано; компонентные — регрессии в формах, таблицах и модалках быстрее браузерных наборов.

На интервью: сравните Pact-подобный контракт с замоканным unit и объясните, когда component заменяет, а не дублирует E2E.

Типовые ошибки: контракты, копирующие детали реализации; компонент без router/query-контекста; раздутые «компонентные» тесты, по сути E2E.

Компромисс — узкий scope ради скорости: контракты и компоненты не видят оркестрацию между сервисами, которую показывает только E2E.

Чеклист:

• Сформулируйте, что контракт гарантирует и чего не может.
• Монтируйте компонент с реалистичными границами (данные, роутинг, тема).
• Держите component-тесты на одном поведенческом срезе.