Це правильне використання методу скидання Mockito?

У моєму тестовому класі у мене є приватний метод, який конструює об'єкт, що часто використовується Bar. BarКонструктор викликає someMethod()метод в моєму знущалися об'єкта:

private @Mock Foo mockedObject; // My mocked object
...

private Bar getBar() {
  Bar result = new Bar(mockedObject); // this calls mockedObject.someMethod()
}

У деяких моїх методах тестування, на які я хочу перевірити, someMethodтакож використовувався саме цей тест. Щось таке:

@Test
public void someTest() {
  Bar bar = getBar();

  // do some things

  verify(mockedObject).someMethod(); // <--- will fail
}

Це не вдається, тому що глузливий об’єкт someMethodвикликав двічі. Я не хочу, щоб мої методи тестування піклувались про побічні ефекти мого getBar()методу, тому було б розумним скинути мій об'єкт макетів наприкінці getBar()?

private Bar getBar() {
  Bar result = new Bar(mockedObject); // this calls mockedObject.someMethod()
  reset(mockedObject); // <-- is this OK?
}

Запитую, оскільки документація передбачає скидання макетних об'єктів, як правило, свідчить про погані тести. Однак мені це добре.

Альтернатива

Альтернативний вибір, схоже, закликає:

verify(mockedObject, times(2)).someMethod();

що, на мій погляд, змушує кожен тест знати про очікування getBar(), без вигоди.

Я вважаю, що це один із випадків, коли використання reset()нормально. Тест, який ви пишете, перевіряє те, що "деякі речі" викликають один дзвінок someMethod(). Написання verify()заяви з будь-якою різною кількістю викликів може призвести до плутанини.

• atLeastOnce() допускає помилкові позитиви, що погано, оскільки ви хочете, щоб ваші тести завжди були правильними.
• times(2)запобігає хибному позитиву, але робить здається, що ви очікуєте двох викликів, а не сказати "я знаю, що конструктор додає один". Крім того, якщо щось зміниться в конструкторі, щоб додати додатковий виклик, тест тепер має шанс на помилковий позитив. І видалення виклику призведе до того, що тест не вдасться, оскільки тест зараз неправильний, а не те, що тестується, є неправильним.

Використовуючи reset()метод helper, ви уникаєте обох цих проблем. Однак вам потрібно бути обережними, що це також скине будь-які заглушки, які ви зробили, тому будьте попереджені. Основна причина, яка reset()не рекомендується - це запобігання

bar = mock(Bar.class);
//do stuff
verify(bar).someMethod();
reset(bar);
//do other stuff
verify(bar).someMethod2();

Це не те, що намагається робити ОП. ОП, я припускаю, має тест, який підтверджує виклик у конструкторі. Для цього тесту скидання дозволяє виділити цю єдину дію та її ефект. Цей один з небагатьох випадків reset()може бути корисним як. Інші варіанти, які використовують не всі, мають свої мінуси. Той факт, що ОП виступив на цій посаді, свідчить про те, що він думає про ситуацію, а не просто сліпо використовуючи метод скидання.

Користувачі Smart Mockito навряд чи використовують функцію скидання, оскільки вони знають, що це може бути ознакою поганих тестів. Зазвичай вам не потрібно скидати макети, просто створюйте нові макети для кожного методу тестування.

Замість reset()прохання розглянути питання про написання простих, малих та зосереджених методів тестування на тривалих, завищених тестах. Перший потенційний кодовий запах знаходиться reset()в середині тестового методу.

Витягнуто з док-мотів .

Моя порада - намагатися уникати використання reset(). На мою думку, якщо ви двічі зателефонували до якогось методу, це слід перевірити (можливо, це питання доступу до бази даних чи інший тривалий процес).

Якщо ви насправді не переймаєтесь цим, ви можете скористатися:

verify(mockedObject, atLeastOnce()).someMethod();

Зауважте, що це останнє може спричинити помилковий результат, якщо ви зателефонуєте на якийсь метод з getBar, а не після (це неправильна поведінка, але тест не вийде з ладу).

Абсолютно ні. Як це часто буває, труднощі, які виникають при написанні чистого тесту, є головним червоним прапором щодо дизайну вашого виробничого коду. У цьому випадку найкращим рішенням є рефакторинг вашого коду, щоб конструктор Bar не викликав жодних методів.

Конструктори повинні будувати, а не виконувати логіку. Візьміть повернене значення методу і передайте його як параметр конструктора.

new Bar(mockedObject);

стає:

new Bar(mockedObject.someMethod());

Якщо це призведе до дублювання цієї логіки у багатьох місцях, спробуйте створити заводський метод, який можна перевірити незалежно від об'єкта Bar:

public Bar createBar(MockedObject mockedObject) {
    Object dependency = mockedObject.someMethod();
    // ...more logic that used to be in Bar constructor
    return new Bar(dependency);
}

Якщо цей рефакторинг є надто складним, то використовувати reset () - це хороша робота. Але давайте будемо зрозумілі - це означає, що ваш код погано розроблений.