Как вы мокировали окружение в тестах

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

Умеете ли вы изолировать код от окружения и понимаете ли, где мок уместен, а где нужна настоящая зависимость. Следом обычно спрашивают, почему не H2, или как вы тестировали клиент к внешнему API.

Как отвечать

Это вопрос про опыт, так что стройте ответ на своём проекте, по слоям окружения:

• юнит-тесты: Mockito с @ExtendWith(MockitoExtension.class), @Mock и @InjectMocks, when(...).thenReturn(...), ArgumentCaptor для проверки того, что ушло в зависимость. С Mockito 5 inline mock maker включён по умолчанию, поэтому mockStatic и финальные классы работают без дополнительной настройки;
• срезы Spring: @WebMvcTest, @DataJpaTest, бины подменяются через @MockitoBean. Старый @MockBean помечен устаревшим начиная со Spring Boot 3.4;
• внешние HTTP-сервисы: WireMock или MockWebServer поднимают настоящий HTTP-сервер со сценариями, включая таймауты и ответ 500. Для RestClient и RestTemplate есть MockRestServiceServer;
• база и брокеры: Testcontainers с PostgreSQL, Kafka, Redis. Начиная со Spring Boot 3.1 адрес контейнера подставляется через @ServiceConnection, в остальных случаях через @DynamicPropertySource;
• время и конфигурация: в код внедряют Clock, в тесте Clock.fixed(...). Настройки через профиль test и @TestPropertySource.

Добавьте, почему выбрали именно так, и конкретику: сколько тестов, сколько шёл прогон, какой баг поймали благодаря контейнеру, а не моку. Если работали только с Mockito, не приписывайте себе Testcontainers, а скажите, что пробовали или как внедрили бы.

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

Мокают всё подряд, включая то, что тестируется. Тест проверяет, что методы вызваны в нужном порядке, и ломается на любом рефакторинге, не поймав ни одного бага.

Берут H2 вместо реальной СУБД. Диалект, типы, jsonb, блокировки отличаются, и тест зелёный там, где прод падает.

Раскидывают разные @MockitoBean по десяткам тестовых классов. Каждая комбинация моков создаёт новый контекст Spring, кеш контекстов не срабатывает, и прогон растягивается в разы.