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, наприклад весняний.
Зараз моя рекомендація змінилася. Команда Mockito додала нову функцію, оскільки я вперше написала цю відповідь. Це правило JUnit, яке виконує точно таку ж функцію, як і MockitoJUnitRunner. Але це краще, тому що це не виключає використання інших бігунів.
Включати
@Rule
public MockitoRule rule = MockitoJUnit.rule();
у вашому тестовому класі. Це ініціалізує макети та автоматизує перевірку фреймворку; так само, як MockitoJUnitRunnerце робить. Але тепер ви можете також використовувати SpringJUnit4ClassRunnerбудь-який інший JUnitRunner. Починаючи з Mockito 2.1.0, є додаткові параметри, які точно контролюють, про які проблеми повідомляються.