Mockito: как создать идеальную тестовую среду

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

Mockito позволяет создавать «подставные» объекты (моки), которые имитируют поведение реальных объектов в контролируемой среде. Это как если бы у вас была возможность создать двойника любого человека, который будет делать ровно то, что вы ему скажете – мечта любого интроверта, не так ли?

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

Прежде чем мы углубимся в детали работы с Mockito, важно отметить — для эффективного использования этого инструмента необходимо хорошо владеть основами Java. Если вы чувствуете, что вам не хватает базовых знаний или хотите структурировать имеющиеся, посмотрите нашу подборку курсов по Java программированию. Там вы найдете образовательные программы разного уровня — от основ до продвинутых техник разработки, включая работу с фреймворками тестирования.

Установка и настройка Mockito

Итак, вы решили пригласить Mockito на вечеринку своего проекта. Отличный выбор! Теперь давайте разберемся, как его туда доставить, не уронив по дороге.

Если вы используете Maven (и да, я знаю, что некоторые из вас все еще используют Ant – не стесняйтесь, мы все делаем ошибки), добавьте следующую зависимость в свой pom.xml:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>3.11.2</version>
    <scope>test</scope>
</dependency>

Для поклонников Gradle (потому что кому не нравится писать build-скрипты на Groovy?) используйте:

testImplementation 'org.mockito:mockito-core:3.11.2'

Теперь, если вы используете JUnit 5 (потому что жить на острие технологий – это про вас), вам понадобится еще немного магии. Добавьте аннотацию @ExtendWith(MockitoExtension.class) к вашему тестовому классу:

import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class MyAmazingTest {
    // Здесь будет ваш потрясающий код
}

Для тех, кто все еще верен JUnit 4 (ностальгия – это нормально), используйте @RunWith(MockitoJUnitRunner.class):

import org.junit.runner.RunWith;
import org.mockito.junit.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class MySlightlyLessAmazingButStillGreatTest {
    // Код, который заставит ваших коллег завидовать
}

Вуаля! Теперь Mockito готов помочь вам в создании иллюзий… то есть, я хотел сказать, в написании надежных юнит-тестов.

Основные понятия: Mock, Spy, Stub

Добро пожаловать в зоопарк Mockito! Здесь у нас водятся три удивительных создания: Mock, Spy и Stub. Давайте познакомимся с каждым из них поближе, не забывая при этом держать руки при себе – они могут укусить (ну, на самом деле нет, но звучит драматичнее).

Диаграмма Венна, иллюстрирующая пересечения и различия между Mock, Spy и Stub в Mockito, успешно создана

Mock

Mock – это искусственный объект, который притворяется настоящим. Как актер, играющий роль разработчика в голливудском фильме – выглядит как разработчик, говорит как разработчик, но на самом деле понятия не имеет, как работает HashMap.

List<String> mockedList = Mockito.mock(List.class);
Mockito.when(mockedList.get(0)).thenReturn("first");
System.out.println(mockedList.get(0)); // Выведет "first"

Spy

Spy – это частичный мок. Представьте, что вы надели на настоящий объект шпионский плащ. Он все еще настоящий объект, но теперь вы можете подслушивать его разговоры и даже заставлять его говорить то, что вам нужно. Немного жутковато, не правда ли?

List<String> list = new ArrayList<>();
List<String> spyList = Mockito.spy(list);
spyList.add("one");
spyList.add("two");
Mockito.verify(spyList).add("one");
Mockito.verify(spyList).add("two");

Stub

Stub – это упрощенная реализация интерфейса или класса. Это как если бы вы заменили сложный механизм на картонную коробку с надписью «Тут что-то происходит». Не очень впечатляюще, но для тестов часто более чем достаточно.

// Создаем stub для интерфейса
Comparable<String> stub = Mockito.stub(Comparable.class);
Mockito.when(stub.compareTo("Mockito")).thenReturn(1);
Assert.assertEquals(1, stub.compareTo("Mockito"));

Теперь давайте рассмотрим, когда использовать каждый из этих подходов:

• Mock: Используйте, когда хотите полностью контролировать поведение объекта.
  • Преимущества:
    • Полный контроль над поведением
    • Изоляция тестируемого кода
    • Возможность симуляции сложных сценариев
• Spy: Применяйте, когда нужно частично подменить поведение реального объекта.
  • Преимущества:
    • Сохранение части реального поведения
    • Возможность верификации вызовов
    • Гибкость в настройке
• Stub: Идеален для замены зависимостей простыми реализациями.
  • Преимущества:
    • Простота создания и использования
    • Быстродействие в тестах
    • Отсутствие сложной логики

Создание Mock объектов

Создать Mock объект в Mockito так же просто, как заказать пиццу. Только вместо теста и пепперони у нас будут классы и интерфейсы.

// Используем Mockito.mock()
List mockedList = Mockito.mock(List.class);

// Или с помощью аннотации @Mock
@Mock
List anotherMockedList;

А теперь представьте, что вы ленивый разработчик (да-да, я знаю, это сложно представить). Вам не хочется вручную внедрять все эти моки? Тогда @InjectMocks спешит на помощь!

public class MyService {
    private List<String> list;
    private Map<String, String> map;
    
    // конструктор, геттеры, сеттеры...
}

@Mock
List<String> mockedList;

@Mock
Map<String, String> mockedMap;

@InjectMocks
MyService service;

Voila! Mockito автоматически внедрит mockedList и mockedMap в service. Это как если бы у вас был личный ассистент, который делает всю скучную работу, пока вы занимаетесь действительно важными вещами. Например, спорите в интернете о табах и пробелах.

Стандартные методы Mockito

Добро пожаловать в арсенал Mockito! Здесь у нас собраны инструменты, способные превратить ваши тесты в настоящие шедевры обмана и манипуляции. Не волнуйтесь, в мире разработки это считается комплиментом.

when() и thenReturn()

Эта парочка — как Бонни и Клайд мира тестирования. Они позволяют вам указать, что должен вернуть метод при определенных условиях.

List<String> mockedList = Mockito.mock(List.class);
when(mockedList.get(0)).thenReturn("первый элемент");
System.out.println(mockedList.get(0)); // Выведет "первый элемент"

doReturn()

Если when().thenReturn() — это Бонни и Клайд, то doReturn() — это их хитрый кузен, который умеет делать то же самое, но задом наперед. Особенно полезен, когда вы работаете с void методами или шпионами.

List<String> spyList = Mockito.spy(new ArrayList<>());
doReturn("шпионские штучки").when(spyList).get(0);
System.out.println(spyList.get(0)); // Выведет "шпионские штучки"

verify()

Этот метод — как детектор лжи для ваших моков. Он проверяет, действительно ли метод был вызван так, как вы ожидали.

List<String> mockedList = Mockito.mock(List.class);
mockedList.add("один");
mockedList.clear();

verify(mockedList).add("один");
verify(mockedList).clear();

Давайте соберем все это в удобную таблицу, чтобы вы могли повесить ее на стену и любоваться перед сном:

Помните, что с большой силой приходит большая ответственность. Используйте эти методы мудро, и пусть сила Mockito будет с вами!

Тестирование поведения: проверка вызовов и порядка

Добро пожаловать в детективное агентство Mockito! Здесь мы будем выяснять, кто кого вызвал, сколько раз и в каком порядке. Прямо как в сериале про офисные интриги, только с меньшим количеством кофе и большим количеством кода.

Проверка вызовов с помощью verify()

Метод verify() — это ваш верный Ватсон в мире юнит-тестирования. Он поможет вам убедиться, что определенный метод был вызван ровно столько раз, сколько нужно, и с теми параметрами, которые вы ожидаете.

List<String> mockedList = mock(List.class);
mockedList.add("один");
mockedList.add("два");
mockedList.add("три");

verify(mockedList).add("один");
verify(mockedList, times(3)).add(anyString());
verify(mockedList, never()).add("четыре");

Но постойте, это еще не все! У verify() есть целая армия помощников-модификаторов:

• times(int): «Я видел, как это случилось ровно N раз!»
• never(): «Этого никогда не было, я клянусь!»
• atLeastOnce(): «Ну, это было как минимум раз, я уверен.»
• atLeast(int): «Это случилось по крайней мере N раз, не меньше!»
• atMost(int): «Эй, притормози! Это было не больше N раз.»

verify(mockedList, times(2)).add(anyString());
verify(mockedList, never()).clear();
verify(mockedList, atLeastOnce()).add("два");
verify(mockedList, atLeast(2)).add(anyString());
verify(mockedList, atMost(3)).add(anyString());

Проверка порядка вызовов

А теперь представьте, что вы — хореограф, и ваш код должен танцевать точно по нотам. Для этого у нас есть InOrder:

List<String> singleMock = mock(List.class);

singleMock.add("был вызван первым");
singleMock.add("был вызван вторым");

InOrder inOrder = inOrder(singleMock);

inOrder.verify(singleMock).add("был вызван первым");
inOrder.verify(singleMock).add("был вызван вторым");

Но что, если у нас целый ансамбль моков? Не проблема!

List<String> firstMock = mock(List.class);
List<String> secondMock = mock(List.class);

firstMock.add("первый");
secondMock.add("второй");
firstMock.add("третий");

InOrder inOrder = inOrder(firstMock, secondMock);

inOrder.verify(firstMock).add("первый");
inOrder.verify(secondMock).add("второй");
inOrder.verify(firstMock).add("третий");

Помните, с большой силой приходит большая ответственность. Не увлекайтесь чрезмерной проверкой порядка вызовов — это может сделать ваши тесты хрупкими и трудноподдерживаемыми. Используйте эту технику мудро, как настоящий мастер кунг-фу использует свои приемы — только когда это действительно необходимо.

В конце концов, цель Mockito — не превратить ваши тесты в детективный роман, а помочь вам убедиться, что ваш код работает так, как нужно. Но если вы всё-таки напишете детективный роман о приключениях храброго разработчика в мире юнит-тестирования, дайте мне знать. Я бы это почитал!

Расширенные возможности Mockito

Добро пожаловать в высшую лигу Mockito! Здесь мы будем жонглировать ArgumentCaptor’ами и балансировать на тонкой грани между реальностью и симуляцией с помощью Spies. Пристегните ремни, будет интересно!

ArgumentCaptor: ловец аргументов в дикой природе

Представьте, что вы — натуралист, исследующий поведение редкого вида аргументов в их естественной среде обитания. ArgumentCaptor — это ваша супер-камера с ночным видением и замедленной съемкой.

@Captor
ArgumentCaptor<List<String>> listCaptor;

@Test
public void shouldCaptureList() {
    List<String> asList = Arrays.asList("someElement_test", "someElement");
    final List<String> mockedList = mock(List.class);
    mockedList.addAll(asList);
    
    verify(mockedList).addAll(listCaptor.capture());
    
    final List<String> capturedArgument = listCaptor.getValue();
    assertEquals(asList, capturedArgument);
    assertEquals("someElement", capturedArgument.get(1));
}

В этом примере мы не просто проверяем, был ли вызван метод addAll(), мы захватываем его аргумент и можем исследовать его вдоль и поперек. Это как если бы вы могли остановить время, вытащить аргумент из метода, повертеть его в руках, а потом вернуть обратно, и никто бы ничего не заметил!

Spies: двойные агенты в мире объектов

Spy — это что-то среднее между реальным объектом и моком. Представьте, что вы надели на обычный объект шпионский плащ и дали ему секретное задание.

@Spy
List<String> spiedList = new ArrayList<>();

@Test
public void testSpy() {
    spiedList.add("one");
    spiedList.add("two");

    verify(spiedList).add("one");
    verify(spiedList).add("two");

    assertEquals(2, spiedList.size());

    doReturn(100).when(spiedList).size();
    assertEquals(100, spiedList.size());
}

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

Пример использования Spies

Давайте рассмотрим более сложный пример использования Spy:

public class DataProcessor {
    public List<String> processData(List<String> data) {
    	return data.stream()
               	.filter(item -> item.length() > 3)
               	.map(String::toUpperCase)
               	.collect(Collectors.toList());
    }
}

@Test
public void testDataProcessorWithSpy() {
    DataProcessor processor = new DataProcessor();
    List<String> inputData = Arrays.asList("a", "ab", "abc", "abcd", "abcde");
    
    List<String> spyList = spy(new ArrayList<>());
    when(spyList.stream()).thenCallRealMethod();
    
    doReturn(inputData).when(spyList).subList(anyInt(), anyInt());
    
    List<String> result = processor.processData(spyList);
    
    assertEquals(Arrays.asList("ABCD", "ABCDE"), result);
    verify(spyList).stream();
    verify(spyList).subList(anyInt(), anyInt());
}

В этом примере мы создаем Spy из ArrayList, но подменяем поведение метода subList(). Это позволяет нам контролировать входные данные, не изменяя реальную реализацию stream() и других методов. Такой подход может быть полезен, когда вы хотите протестировать сложную логику обработки данных, но при этом контролировать источник этих данных.

Помните, что с большой силой приходит большая ответственность. Использование Spy может сделать ваши тесты более гибкими, но также может сделать их более сложными для понимания и поддержки. Используйте эту технику мудро, как Джеймс Бонд использует свои гаджеты — только когда это действительно необходимо и эффективно.

Подходы к тестированию с Mockito

Добро пожаловать в мир Behavior Driven Development (BDD) с Mockito! Здесь мы не просто пишем тесты, мы рассказываем истории. Истории о том, как ваш код должен себя вести, когда вырастет и станет большим и сильным приложением.

BDD с Mockito: когда тесты читаются как проза

BDD подход в тестировании позволяет нам писать тесты, которые читаются почти как обычные предложения. Это как если бы вы объясняли работу вашего кода своей бабушке… ну, может быть, очень технически подкованной бабушке.

Давайте посмотрим, как это выглядит на практике:

import static org.mockito.BDDMockito.*;

public class OrderServiceTest {

    @Mock
    private InventoryService inventoryService;
    
    @InjectMocks
    private OrderService orderService;

    @Test
    public void givenInStockProduct_whenPlaceOrder_thenOrderIsPlaced() {
    	// Given
    	given(inventoryService.isInStock("ABC123")).willReturn(true);
    	Order order = new Order("ABC123", 1);

    	// When
    	boolean orderPlaced = orderService.placeOrder(order);

    	// Then
    	then(inventoryService).should().isInStock("ABC123");
    	assertThat(orderPlaced).isTrue();
    }
}

Заметьте, как этот тест читается почти как история:

1. Given (Дано): у нас есть товар в наличии
2. When (Когда): мы пытаемся разместить заказ
3. Then (Тогда): заказ должен быть размещен успешно

Это не просто синтаксический сахар, это целая философия. Мы не просто проверяем, работает ли код, мы описываем ожидаемое поведение системы.

BDDMockito: ваш личный писатель технических романов

Mockito предоставляет специальный класс BDDMockito, который содержит методы, семантически более подходящие для BDD стиля:

• given() вместо when()
• willReturn() вместо thenReturn()
• then() вместо verify()

Давайте рассмотрим еще один пример:

@Test
public void givenOutOfStockProduct_whenPlaceOrder_thenOrderIsRejected() {
    // Given
    String productId = "XYZ789";
    given(inventoryService.isInStock(productId)).willReturn(false);
    Order order = new Order(productId, 1);

    // When
    boolean orderPlaced = orderService.placeOrder(order);

    // Then
    then(inventoryService).should(times(1)).isInStock(productId);
    then(inventoryService).shouldHaveNoMoreInteractions();
    assertThat(orderPlaced).isFalse();
}

Видите, как легко читать и понимать этот тест? Даже если вы не знаете всех деталей реализации, вы можете понять, что происходит:

1. Дано, что продукт отсутствует на складе
2. Когда мы пытаемся разместить заказ
3. Тогда заказ должен быть отклонен, и мы должны проверить наличие товара ровно один раз

Это как если бы вы писали технический роман, где главный герой — ваш код, а злодей — баги, которые вы пытаетесь поймать.

Выводы

Использование BDD подхода с Mockito не только делает ваши тесты более читаемыми и понятными, но и помогает вам мыслить в терминах поведения системы, а не просто проверки отдельных методов. Это может привести к более надежным и поддерживаемым тестам, а также помочь в коммуникации между разработчиками, тестировщиками и бизнес-аналитиками.

Помните, хороший тест — это не просто проверка кода, это документация поведения вашей системы. И с Mockito в стиле BDD вы можете писать эту документацию так, что даже ваш менеджер проекта сможет ее понять… ну, может быть, после пары чашек кофе.

Полезные советы и лучшие практики

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

Не увлекайтесь!

Помните, Mockito — это инструмент, а не волшебная палочка. Не пытайтесь мокировать весь мир. Иногда реальные объекты работают лучше, чем моки. Это как с фастфудом — вкусно, но злоупотреблять не стоит.

Держите тесты в чистоте

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

Будьте конкретны в ожиданиях

Используйте конкретные значения в when() и verify() вместо any(), где это возможно. Ваши тесты должны быть как хороший детектив — с четкими уликами и без лишних подозреваемых.

// Хорошо
when(userService.findById(1L)).thenReturn(user);

// Не очень
when(userService.findById(any())).thenReturn(user);

Не верифицируйте тривиальное

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

Используйте @Captor для сложных аргументов

Когда нужно проверить сложные аргументы, ArgumentCaptor — ваш лучший друг. Он позволяет захватить аргументы и проверить их после вызова метода. Это как словить покемона — сначала поймайте, потом рассматривайте.

Помните о reset()

Метод reset() может быть полезен, но пользуйтесь им с осторожностью. Частое использование reset() может быть признаком того, что ваш тест делает слишком много. Разделяйте большие тесты на маленькие, как пиццу на вечеринке — каждому по кусочку.

Избегайте статических методов

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

Используйте содержательные имена

Давайте моками и тестам понятные имена. fooMock говорит гораздо меньше, чем userRepositoryMock. Хорошее имя для мока — как хорошее имя для кота: должно отражать его суть, а не просто быть набором букв.

Будьте осторожны со шпионами (Spy)

Шпионы (Spy) могут быть полезны, но они также могут сделать ваши тесты хрупкими. Используйте их мудро, как настоящий шпион использует свои гаджеты — только когда это действительно необходимо.

Поддерживайте баланс

Помните, что цель тестирования — убедиться, что ваш код работает правильно, а не достичь 100% покрытия любой ценой. Качество важнее количества. Это как с едой — важно не сколько вы съели, а насколько это было полезно и вкусно.

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

И самое главное — получайте удовольствие от процесса! Тестирование может быть увлекательным, особенно когда у вас есть такой надежный помощник, как Mockito. Удачи в ваших тестовых приключениях!

Заключение

Итак, дорогие читатели, мы с вами совершили увлекательное путешествие в мир Mockito — от простых моков до сложных шпионских игр с ArgumentCaptor’ами. Надеюсь, теперь вы чувствуете себя настоящими магами тестирования, способными создавать иллюзии объектов щелчком пальцев (ну, или нажатием клавиш, если быть точным).

Давайте вспомним, чему мы научились:

1. Мы узнали, что Mockito — это не итальянский коктейль, а мощный фреймворк для тестирования Java-приложений.
2. Мы освоили искусство создания моков и стабов, превратившись в кукловодов мира объектов.
3. Мы научились шпионить за методами с помощью verify(), как настоящие агенты 007 в мире кода.
4. Мы погрузились в мир BDD, где тесты читаются как увлекательные истории (правда, только для очень странных любителей технической литературы).
5. И наконец, мы собрали целую коллекцию полезных советов, которые помогут нам писать тесты, достойные места в музее программирования (если бы такой существовал).

Помните, что Mockito — это всего лишь инструмент, а настоящая магия происходит в вашей голове. Используйте его мудро, и пусть ваши тесты будут такими же надежными, как швейцарские часы, и такими же элегантными, как код после рефакторинга.

И напоследок, не забывайте главное правило тестирования с Mockito: если ваши тесты не вызывают у вас улыбку (или хотя бы ухмылку), вы делаете что-то не так. Веселого вам кодинга и да пребудет с вами сила Mockito!