Контрактные тесты проверяют, что провайдер API не ломает ожидания потребителя: потребитель фиксирует, какие запросы делает и какие поля читает, провайдер в своей сборке проверяет, что выполняет все контракты.
А ещё Проверяют совместимость формата, а не бизнес-логику
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Проблема: сервис A вызывает сервис B. Unit-тесты A используют заглушку B, которая может не совпадать с реальным B. Сквозные тесты всей системы медленные, хрупкие и требуют поднять всё окружение.
Контракт — описание взаимодействия: запрос (метод, путь, заголовки, тело) и ожидаемый ответ (статус, нужные поля и их типы).
Consumer-driven (Pact):
sottocan-i-deploy перед выкаткой проверяет совместимость версий.Spring Cloud Contract: контракты пишутся в Groovy или YAML; плагин генерирует тесты провайдера и стабы WireMock, которые потребитель подключает в тестах (@AutoConfigureStubRunner).
Что даёт: поломка API видна в сборке провайдера до выкатки, без общего окружения; провайдер знает, какие поля реально используются. Чего не даёт: проверки бизнес-логики и всей цепочки — для этого остаются интеграционные тесты сервиса и немного сквозных.
Один верный вариант. Подумайте, потом откройте ответ.
Пирамида тестов, unit без Spring, slice-тесты, @SpringBootTest и @MockBean, MockMvc/WebTestClient, Testcontainers и контрактные тесты.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.