Как обеспечивалось взаимодействие между сервисами в тестах

Что проверяют

Какой у вас реальный опыт тестирования микросервисов и понимаете ли вы, на каком уровне что проверяется. Моки, заглушки HTTP, контрактные тесты и полноценные интеграционные тесты решают разные задачи. Следом спросят, как вы узнавали, что соседний сервис поменял API.

Как отвечать

Отвечайте про свой проект, но раскладывайте по уровням:

• юнит-тесты: клиент соседнего сервиса (Feign, RestClient, WebClient) скрыт за интерфейсом и подменяется через Mockito. Проверяется ваша логика, а не сеть. В Spring Boot 3.4 @MockBean помечен устаревшим, вместо него @MockitoBean;
• заглушки HTTP: WireMock поднимает настоящий HTTP-сервер со стабами, и вы проверяете сериализацию, заголовки, таймауты, ретраи, ответы 500 и 503. Для узкого случая есть @RestClientTest с MockRestServiceServer;
• контрактные тесты: Pact или Spring Cloud Contract. Потребитель фиксирует ожидания, провайдер проверяет их у себя в CI, и расхождение ловится до деплоя, а не на стенде;
• Testcontainers: реальные PostgreSQL, Kafka, Redis в Docker на время теста. Начиная со Spring Boot 3.1 подключаются через @ServiceConnection без ручной настройки свойств;
• асинхронные сценарии: события через Kafka проверяются Awaitility с таймаутом, а не Thread.sleep;
• e2e на стенде: несколько сквозных сценариев, основа пирамиды всё равно ниже.

Назовите свои цифры: сколько сервисов, сколько тестов на каком уровне, сколько идёт прогон, что поймали. Если работали только с моками, так и скажите, объясните, чего не хватало и что добавили бы: обычно это контракты и Testcontainers.

Где спотыкаются

Всё закрыто моками. Тесты зелёные, а в проде падает, потому что провайдер переименовал поле. Без контрактов это не ловится.

Используют Thread.sleep в асинхронных тестах. Получают флаки на медленном CI и долгий прогон на быстром.

Строят тесты на общем стенде с чужими данными. Соседняя команда почистила базу, и половина прогона красная без изменений в коде.