Курсы и обучение Mockito: юнит-тесты на Java, Spring Boot и Kotlin

Зачем разработчику Mockito в 2026 году

Тест, который лезет в базу, дёргает соседний сервис и падает от того, что у коллеги упал стенд, юнит-тестом не является. Это интеграционный тест, который притворяется быстрым. Mockito решает ровно эту проблему: подменяет зависимости заглушками, чтобы проверялась ваша логика, а не сеть и не чужой код.

Библиотека остаётся стандартом в Java-мире больше десяти лет. Её знание перестало быть отдельным достижением и превратилось в базовое требование: на собеседованиях уровня Junior+ и Middle разницу между моком и шпионом спрашивают почти всегда, а умение написать тест с заглушкой проверяют на живом коде.

Учить Mockito в отрыве от JUnit смысла мало. В реальном проекте это связка: JUnit запускает тесты и проверяет результат, Mockito подставляет окружение.

Mock, Spy и Stub: в чём разница

Три слова, которые новички путают чаще всего, и на которых спотыкаются на собеседовании. Разница не в синтаксисе, а в том, сколько настоящего объекта остаётся внутри.

Практический ориентир: начинайте с мока. Шпион выглядит удобнее, но тянет за собой настоящую логику класса, и тест начинает падать из-за кода, который вы вообще не собирались проверять. Если тянет поставить @Spy, часто это сигнал, что класс делает слишком много и просится на разделение.

Базовый набор Mockito: when, verify и ArgumentCaptor

Рабочий словарь библиотеки небольшой. Четырёх конструкций хватает на подавляющее большинство тестов.

Задать ответ. when(repo.findById(1L)).thenReturn(user), самая частая строчка в любом проекте. Рядом живёт thenThrow(), когда надо проверить обработку ошибки.

Проверить вызов. verify(sender).send(msg) отвечает на вопрос «метод вообще позвали?». С модификаторами становится точнее: times(2), never(), atLeastOnce(). Для void-методов это единственный способ хоть что-то проверить: возвращать им нечего.

Поймать аргумент. ArgumentCaptor перехватывает то, что улетело в мок. Полезно, когда объект собирается внутри тестируемого метода и снаружи его не достать: захватили, развернули, проверили поля.

Ослабить строгость. Начиная с пятой версии Mockito ругается на настроенные, но не использованные заглушки, и это защита от мусора в тестах. Точечно её снимает lenient(). Пользоваться этим стоит редко: чаще лишний стаб означает, что тест проверяет не то, что задумывалось.

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

Что изменилось в Mockito 5 и почему старые гайды подводят

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

Актуальная линейка пятая, свежий релиз 5.23.0 вышел 11 марта 2026 года. Три вещи, которые ломают старые инструкции:

• Inline mock maker включён по умолчанию. Раньше, чтобы замокать статический метод или финальный класс, подключали отдельный артефакт mockito-inline. Теперь это поведение встроено в mockito-core.
• Артефакт mockito-inline больше не публикуется: его перестали выкладывать с версии 5.3.0. Если он остался в вашем pom.xml, его нужно просто убрать.
• Минимум Java 11. Проектам на Java 8 придётся остаться на четвёртой ветке.

Старый механизм никуда не делся: кому нужен прежний subclass-подход, подключают mockito-subclass. А PowerMock, который годами таскали ради статики, для новых проектов стал не нужен.

Проверяйте это, когда читаете обучающие материалы. Гайд, где мокирование статики объясняется через mockito-inline, написан до 2023 года, и примеры оттуда на свежем проекте не соберутся.

Четыре ошибки, на которых буксуют новички

Первая: мокать всё подряд. Если в тесте пять заглушек, проверяется уже не логика, а ваша способность правильно настроить моки. Такой тест зеленеет, даже когда продакшен-код сломан.

Вторая: мокать то, что вам не принадлежит. Заглушка для чужого HTTP-клиента фиксирует ваше представление о том, как он себя ведёт. Библиотека обновится, поведение изменится, а тест продолжит показывать зелёный.

Третья: проверять вызовы вместо результата. verify() уместен там, где у метода нет возвращаемого значения. Если результат есть, проверяйте его, иначе тест намертво привязывается к внутренней реализации и падает при любом рефакторинге.

Четвёртая: мокать объекты-значения. DTO, entity и прочие простые структуры дешевле собрать конструктором, чем городить вокруг них заглушки.

Как подключить Mockito к проекту на Maven и Gradle

Для Maven в pom.xml добавляют org.mockito:mockito-core со scope test. Для связки с JUnit 5 нужен второй артефакт mockito-junit-jupiter, он приносит расширение MockitoExtension.

В Gradle то же самое одной строкой: testImplementation "org.mockito:mockito-core:5.+", такой вариант рекомендует сайт проекта.

Дальше над тестовым классом ставится @ExtendWith(MockitoExtension.class), зависимости помечаются @Mock, а тестируемый объект @InjectMocks. Аннотации избавляют от ручного вызова mock() в каждом тесте.

Тонкость, о которой забывают: если проект ещё на JUnit 4, расширение не сработает, там был @RunWith(MockitoJUnitRunner.class). Правила запуска описаны в руководстве JUnit 5.

Mockito в Spring Boot и Kotlin

В Spring-приложениях моки чаще всего подставляют не руками, а через контекст. Аннотация подменяет бин на заглушку, весь остальной контекст поднимается как обычно. Так тестируют сервисы, не поднимая базу. Разбирают это на программах по Spring Boot, обычно ближе к концу модуля о тестировании.

С Kotlin есть отдельная сложность: там классы и методы по умолчанию финальные. На четвёртой ветке это лечили плагином или открытием классов вручную, сейчас inline-мокер справляется сам. Синтаксис всё равно остаётся неудобным из-за null-safety, поэтому в Kotlin-проектах часто берут обёртку mockito-kotlin или уходят на MockK.

Чему учат на курсах, где есть Mockito

Программа обычно строится от простого к сложному: сначала основы юнит-тестирования и первый мок, затем проверка поведения, и уже потом тесты сервисного слоя в Spring.

Типичный набор тем:

• Что вообще имеет смысл покрывать юнит-тестами, а что нет
• Разница между Mock, Spy и Stub на рабочих примерах
• Настройка ответов через when().thenReturn() и проверка исключений
• Верификация вызовов, работа с void-методами, ArgumentCaptor
• Мокирование статических методов и финальных классов
• Тесты сервисов в Spring Boot без поднятия базы данных
• Место юнит-тестов в CI/CD и метрики покрытия

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

Сколько стоит обучение

Цены в каталоге начинаются от 47 613 ₽ и доходят до 170 000 ₽, медиана составляет 125 000 ₽. Разброс объясняется форматом: короткий курс по автоматизации тестирования стоит заметно меньше, чем годовая программа «Java-разработчик с нуля», где тестирование идёт одним из модулей.

Большинство школ дают рассрочку, так что помесячный платёж отличается от цены в прайсе в разы. Смотреть стоит не на общую сумму, а на то, сколько часов программы приходится на тестирование: иногда дешёвый интенсив даёт по этой теме больше, чем дорогая профессия.

Курс, документация или самостоятельная практика

У Mockito низкий порог входа, и это честно стоит сказать вслух. Базовый синтаксис осваивается за пару вечеров по документации. Вопрос в том, что делать дальше.

Отсюда практический вывод: ради одной библиотеки курс не покупают. Его берут, когда цель шире: войти в Java-разработку или перейти из ручного тестирования ПО в автоматизацию, а Mockito идёт частью маршрута.

Кому стоит разобраться с Mockito

Java-разработчику, у которого тесты падают из-за недоступной базы или упавшего стенда. Изоляция зависимостей превращает получасовой прогон в секунды и убирает мигающие тесты, которые команда со временем начинает игнорировать.

Ручному тестировщику, который идёт в автоматизацию на Java. Понимание тестовых двойников это точка, где заканчиваются клики по интерфейсу и начинается инженерная работа. Маршрут этого перехода мы разбирали в материале о том, как стать Java-разработчиком, а требования рынка собраны в обзоре профессии QA-инженера.

Android-разработчику. Здесь Mockito традиционно силён, хотя в Kotlin-проектах у него есть конкуренты. Языки и их инструменты тестирования мы сравнивали в разборе Java или Kotlin.

Кому библиотека не нужна: тем, кто пишет на других языках. Идея тестовых двойников универсальна, но синтаксис и подводные камни у Mockito свои.

Как мы отбираем программы в каталог

Сразу оговоримся, чтобы не создавать ложных ожиданий: курсов, посвящённых только Mockito, российский рынок не выпускает. Библиотека слишком компактная, чтобы растянуть её на отдельную программу. Её изучают модулем внутри курсов по Java-разработке, автоматизации тестирования и Spring.

Поэтому в подборке 9 курсов от 6 школ это программы, где тестирование с моками входит в состав, а не разовые вебинары про одну аннотацию. При отборе смотрим на три вещи:

• Актуальность стека. Пятая ветка Mockito и JUnit 5. Если в программе всё ещё mockito-inline и JUnit 4, значит материал писали давно и с тех пор не трогали.
• Практика на сервисном слое. Тесты для Spring Boot приложения, а не абстрактные примеры с калькулятором.
• Ревью кода. Возможность показать свои тесты практикующему инженеру и получить разбор.

Фильтры сверху помогают сузить выбор по цене, длительности и наличию документа об окончании. Если вам нужен именно короткий вход в тему, начните с раздела JUnit: там программы с более выраженным акцентом на тестирование.