@RunWith (MockitoJUnitRunner.class) против MockitoAnnotations.initMocks (это)

MockitoJUnitRunner дает вам автоматическое подтверждение использования фреймворка, а также автоматическое initMocks().

Автоматическая проверка использования фреймворка действительно стоит того. Если вы сделаете одну из этих ошибок, это даст вам лучший отчет.

• Вы вызываете статический метод when, но не завершаете заглушку соответствующими thenReturn, thenThrow или then. (Ошибка 1 в приведенном ниже коде)

• Вы вызываете verify как имитацию, но забываете предоставить вызов метода, который вы пытаетесь проверить. (Ошибка 2 в приведенном ниже коде)

• Вы вызываете метод when после doReturn, doThrow или doAnswer и передаете имитацию, но забываете предоставить метод, который пытаетесь заглушить. (Ошибка 3 в приведенном ниже коде)

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

• в том же методе тестирования (например, ошибка 1 ниже),
• в следующем методе тестирования (например, ошибка 2 ниже),
• в следующем тестовом классе.

Если они возникнут в последнем запущенном вами тесте (например, ошибка 3 ниже), о них вообще не будет сообщено.

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

@Test
public void test1() {

    // ERROR 1
    // This compiles and runs, but it's an invalid use of the framework because 
    // Mockito is still waiting to find out what it should do when myMethod is called.
    // But Mockito can't report it yet, because the call to thenReturn might 
    // be yet to happen.
    when(myMock.method1());

    doSomeTestingStuff();

    // ERROR 1 is reported on the following line, even though it's not the line with
    // the error.
    verify(myMock).method2();

}

@Test
public void test2() {

    doSomeTestingStuff();

    // ERROR 2
    // This compiles and runs, but it's an invalid use of the framework because
    // Mockito doesn't know what method call to verify.  But Mockito can't report 
    // it yet, because the call to the method that's being verified might 
    // be yet to happen.
    verify(myMock);
}

@Test
public void test3() {

    // ERROR 2 is reported on the following line, even though it's not even in 
    // the same test as the error.
    doReturn("Hello").when(myMock).method1();


    // ERROR 3
    // This compiles and runs, but it's an invalid use of the framework because
    // Mockito doesn't know what method call is being stubbed.  But Mockito can't 
    // report it yet, because the call to the method that's being stubbed might 
    // be yet to happen.

    doReturn("World").when(myMock);

    doSomeTestingStuff(); 

    //  ERROR 3 is never reported, because there are no more Mockito calls. 
}

Когда я впервые написал этот ответ более пяти лет назад, я написал

Поэтому я бы рекомендовал использовать MockitoJUnitRunner везде, где это возможно. Однако, как правильно заметил Томаш Нуркевич, вы не можете использовать его, если вам нужен другой бегун JUnit, такой как Spring.

Моя рекомендация изменилась. Команда Mockito добавила новую функцию с тех пор, как я впервые написал этот ответ. Это правило JUnit, которое выполняет ту же функцию, что и MockitoJUnitRunner. Но так лучше, потому что это не исключает возможности использования других бегунов.

Включают

@Rule 
public MockitoRule rule = MockitoJUnit.rule();

в вашем тестовом классе. Это инициализирует макеты и автоматизирует проверку фреймворка; прямо как MockitoJUnitRunner. Но теперь вы также можете использовать SpringJUnit4ClassRunner или любой другой JUnitRunner. Начиная с Mockito 2.1.0, есть дополнительные параметры, которые точно определяют, о каких проблемах следует сообщать.

Использование runner позволяет сэкономить немного кода (нет необходимости в методе @Before). С другой стороны, использование бегуна иногда невозможно, т. Е. Когда вы уже используете его, например _ 2_.

Вот и все. Это просто вопрос предпочтения.