Mockito

Тема дорожной карты · Java

Mockito — наиболее широко используемый фреймворк мокирования в экосистеме Java, позволяющий разработчикам изолировать тестируемые единицы путём замены реальных коллабораторов управляемыми мок-объектами во время выполнения тестов JUnit 5. Используя @Mock, @InjectMocks и @ExtendWith(MockitoExtension.class), Mockito чисто интегрируется в тестовые классы JUnit 5 без ручной настройки, а его гибкий API стаббинга — when(mock.method()).thenReturn(value) или given(mock.method()).willReturn(value) через стиль BDDMockito — делает намерение теста немедленно понятным. Mockito поддерживает матчеры аргументов (any(), eq(), argThat()), объекты-шпионы для частичного мокирования через @Spy и проверку взаимодействий через verify(mock).method(args) и verifyNoMoreInteractions(mock), охватывая полный рабочий процесс поведенческой верификации, дополняющий утверждения о состоянии AssertJ. Расширенные возможности Mockito включают @Captor для внедрения ArgumentCaptor, мокирование static-методов через mockStatic() (доступно с Mockito 3.4 через mockito-inline) и глубокое стаббинг для цепочек гибких API. Mockito интегрируется с Spring Boot Test через @MockBean и @SpyBean, делая его основным инструментом для изоляции границ Spring, Hibernate, JDBC и внешних сервисов в пирамиде тестирования Java.

Как это работает

Mockito использует JUnit 5 как де факто unit-test framework (@Test, @ParameterizedTest, @BeforeEach), AssertJ или Hamcrest для fluent-ассертов, Mockito для моков, Testcontainers для подъёма реальных БД/сервисов в Docker для integration-тестов, REST Assured для HTTP API-тестов. Spring Boot имеет свои test-slice (@WebMvcTest, @DataJpaTest), загружающие минимальный контекст.

Когда применять

JUnit 5 + AssertJ — дефолтный стек. Testcontainers — для любого кода, касающегося реальной БД; мок БД прячет реальные баги (constraint violations, ошибки запроса). Mockito — осторожно; over-mocking тестирует мок, не код. Тесты в CI на каждый PR; валите билды на flake.

Типичные ошибки

Ловушки Mockito: тесты, делящие state через static-поля; мокинг всего, пока тест — это просто verify(...)-вызовы; медленные Spring Boot integration-тесты, потому что каждый тест поднимает весь контекст (используйте slice-тесты); flaky-тесты оставлены — каждый подрывает доверие.

Связанные понятия

Полезные ресурсы