Как проверить, что одно из многих условий выполнено на Мокито?Можно ли проверить, был ли вызван один ИЛИ другой метод?

Question

В моем модульном тесте я хочу проверить, был ли вызван тот или иной метод. Я легко могу проверить, сколько раз некоторые методы вызываются благодаря Mockito, но verify не имеет режима проверки, такого как «ИЛИ». Есть обходные пути?

В моем случае я хочу проверить, назывался ли SharedPreferences.Editor .apply() или .commit(), потому что две из этих возможностей удовлетворяют меня и сохраняют данные. К сожалению, если я позвоню verify(mEditor).apply(), но кто-то изменит реализацию на .commit(), например, из-за необходимости мгновенного сохранения, проверка не будет выполнена, но не должна, потому что я хочу проверять только с этой точки зрения, если данные сохранены или не. Это модульный тест, который должен быть независимым от подобных изменений и проверять только объем того, что тестируется внутри.

Answer 1

Обходной путь, о котором вы просите, состоит в том, чтобы поймать базовую MockitoAssertionError (или просто AssertionError):

try {
  verify(mEditor).apply();
} catch (MockitoAssertionError mae) {
  // apply was not called. Let's verify commit instead.
  verify(mEditor).commit();
}

В качестве альтернативы, если оба значения apply и commitВызвав некоторый (внутренний) save метод, вы также можете попытаться проверить это (при условии, что он открыт - фиктивное тестирование может противоречить скрытию информации).Или, если у вас есть контроль над кодом, который вы тестируете, вы можете реорганизовать его в соответствии с этим.

Тем не менее, лучшим советом было бы избежать необходимости в этом вообще, как утверждается в ответ @ GhostCat .

Answer 2

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

Вы знаете, что должен делать ваш рабочий код.Значение: вместо написания одного фрагмента кода проверки, который позволяет «this или that», лучше написать два независимых теста, один для «this» и один для «that».

Другими словами: вы контролируете то, что входит в ваши тесты.Поэтому напишите один тест, который должен дать apply(), и один, который должен дать commit().И затем verify() этот один случай, который должен увидеть каждый тест!

Модульные тесты должны быть простыми.Когда что-то не получается, вы быстро просматриваете модульный тест и уже знаете, где искать производственный код, чтобы определить причину.Все, что добавляет сложности вашим тестам, может усложнить задачуЛучше иметь два теста, которые следуют четкому пути «когда проверять», вместо того, чтобы иметь один (или несколько) тестов, которые идут «когда проверяют это ИЛИ проверяют это».