Укрощение глупого общего предупреждения

Укрощение глупого общего предупреждения

Разблокировка метода Mockito mock()

Это предупреждение — такая маленькая, неважная вещь, но оно меня давно беспокоило — и теперь я это исправил. В маловероятном случае, если это затронет и вас, позвольте мне показать вам, как справиться с этой проблемой.

Первый (самый первый) пример в документации Mockito:

//Let's import Mockito statically so that the code looks clearer
 import static org.mockito.Mockito.*;

 //mock creation
 List mockedList = mock(List.class);

 //using mock object
 mockedList.add("one");
 mockedList.clear();

 //verification
 verify(mockedList).add("one");
 verify(mockedList).clear();

Честно говоря, это не лучший пример. Во-первых, как указано в документации, вы не должны издеваться над List. Они делают это только потому, что каждый разработчик Java знаком со списками, поэтому они уже понимают вызовы addили clear.

Во-вторых, не проверяйте свои моки. Вы имитируете зависимость, внедряете эту зависимость в тестируемый класс и вызываете методы тестового класса. Этот пример имитирует List, а затем показывает вызовы методов для него, что должно происходить только внутри любого класса, который они на самом деле тестируют.

Я понимаю, хотя. Цель документации не в том, чтобы научить вас использовать макеты и заглушки в тестах Java. На эту тему есть хорошие книги (например, Mockito Made Clear, доступная на Pragmatic Bookshelf). Документы просто пытаются проиллюстрировать Mockito API, и этот пример делает это.

Нет, моя самая большая проблема с этим кодом заключается в том, что если вы введете его в IDE, например IntelliJ IDEA, вы получите следующее:

Видите все эти выделенные предупреждения? Это происходит из-за «необработанного использования параметризованного класса «List»», что было проблемой, начиная с Java 1.5, примерно в 2004 году. Хорошо, это достаточно легко исправить. В примере в список добавляется строка one, поэтому давайте сделаем ссылку List<String>.

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