Используете ли мок объекты в тестах

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

Не сам факт использования моков, а понимание, где они помогают, а где делают тесты хрупкими. Следом обычно спрашивают, чем мок отличается от стаба и фейка и что вы мокаете в тестах сервиса на Spring.

Как отвечать

Ответьте «да» и сразу обозначьте границу: мокаются внешние зависимости, которые медленные, недетерминированные или с побочными эффектами. HTTP-клиенты, брокер, отправка почты, время. Классы с логикой и объекты-значения мокать не нужно.

Терминологию по Мезаросу часто уточняют:

• stub: возвращает заранее заданные ответы, проверяется результат;
• mock: проверяется взаимодействие с ним, через verify;
• spy: реальный объект, у которого подменены отдельные методы;
• fake: рабочая упрощённая реализация, например репозиторий на HashMap.

Инструменты. Mockito: @ExtendWith(MockitoExtension.class), @Mock, @InjectMocks, when(...).thenReturn(...), verify(client, times(1)).send(any()), ArgumentCaptor для проверки аргументов. С Mockito 5 по умолчанию работает inline mock maker, поэтому финальные классы мокаются без настроек, а статические методы через mockStatic в try-with-resources. Строгие стабы в MockitoExtension падают с UnnecessaryStubbingException на лишней настройке, и это полезно. В Spring Boot @MockBean устарел с версии 3.4, на смену пришёл @MockitoBean.

Время удобнее передавать через Clock и в тесте ставить Clock.fixed(...), чем мокать LocalDateTime.now(). Для HTTP есть WireMock, для базы Testcontainers: SQL и маппинг через мок репозитория не проверить.

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

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

Мокают репозиторий в тесте, который должен проверить запрос к базе. Всё зелёное, а на проде запрос падает из-за опечатки в JPQL.

Используют when(spy.method()) на шпионе. Реальный метод вызывается прямо при настройке, для spy нужен doReturn(...).when(spy).method().