☕️ Mockito — как работает мокирование и зачем оно нужно в тестировании В процессе реализации юнит-тестов, применяя различные язык программирования, часто возникает проблема: тестируемый класс зависит от других компонентов. Например: репозиторий, HTTP-клиента, сервис отправки электронных сообщений или продюсер сообщений на основе Apache Kafka. Если в тесте использовать реальные зависимости, то такой тест выйдет за рамки юнит-тестирования и будет больше похож на интеграционный тесты. Как раз для таких случаев и был спроектирован механизм мокирования. ➖ Что такое мокирование? Mock — это тестовый объект, который имитирует поведение реальной зависимости. Так например, в экосистеме Java есть библиотека Mockito позволяющая создать: 🔹создать поддельный объект 🔹задать его поведение 🔹проверить, как он использовался Идея проста: мы тестируем логику класса, а не его внешние зависимости. Вот действенный и эффективный пример, которые в том числе поможет подготовиться к собеседованию. ➖ Представим сервис: public class UserService { private final UserRepository userRepository; private final EmailService emailService; public UserService(UserRepository userRepository, EmailService emailService) { this.userRepository = userRepository; this.emailService = emailService; } public void registerUser(String email) { User user = new User(email); userRepository.save(user); emailService.sendWelcomeEmail(email); } } В данном случае UserService зависит от UserRepository и EmailService. В юнит-тесте нам не нужно реально сохранять пользователя в базу или реально отправлять электронные сообщения. ➖Как это тестируется через Mockito? @ExtendWith(MockitoExtension.class) class UserServiceTest { @Mock private UserRepository userRepository; @Mock private EmailService emailService; @InjectMocks private UserService userService; @Test void shouldRegisterUserAndSendWelcomeEmail() { userService.registerUser("test@example.com"); verify(userRepository).save(any(User.class)); verify(emailService).sendWelcomeEmail("test@example.com"); } } ➖ Что здесь происходит? Аннотация @Mock создает mock-объект. Это означает, что вместо настоящего EmailService будет поддельный объект. Аннотация @InjectMocks создает тестируемый объект и внедряет в него mock-зависимости. То есть UserService будет создан не с реальными зависимостями, а с мок-объектами. Метод verify(...) проверяет, что нужный метод действительно был вызван. Например, код ниже выполняет проверку был ли действительно вызван метод sendWelcomeEmail(...) с контролем переданного аргумента. verify(emailService).sendWelcomeEmail("test@example.com"); ➖ А если нужно вернуть значение? Тогда используется комбинация методов when(...).thenReturn(...) и когда будет вызван метод findByEmail(...), то будет возвращено ожидаемое значение. when(userRepository.findByEmail("test@example.com")) .thenReturn(Optional.of(new User("test@example.com"))); 📌 Зачем это нужно на практике? Mockito полезен, когда нужно проверить была ли вызвана зависимость, с какими параметрами она вызывалась, как класс ведет себя при разных ответах зависимости и что происходит при исключениях. Но, не стоит использовать Mockito бездумно. Плохим тестом можно считать, если он знает слишком много о внутренних вызовах, ломается при простом рефакторинге, тестирует реализацию, а не поведение. При этом, Mocking всегда будет полезен там, где действительно есть внешняя зависимость, например: база данных, сеть, брокер сообщений или файловая система. ⬇️ А тебя просят покрывать свое решение тестами во время на собеседований? Пиши о своем опыте в комментариях. 👍 Понравился этот пост? Подписывайся, ставь лайк и поделись постом с другом или коллегой.