Сравните расширенные классы Mockito со своими обычными коллегами - PullRequest
Новая
       5

Сравните расширенные классы Mockito со своими обычными коллегами

0 голосов
/ 13 ноября 2018

Я создал простой тестовый класс с двумя полями, такими как 

@Mock
private MyTestClass myTestClass;

@Spy
private final MyContext context = CommonTestData.getDefaultContext();

По сути, мне здесь не нужна шпионская функциональность, она просто используется для автоматической инъекции объекта в другие насмешки.

Для теста я попытался настроить myTestClass так: 

when(myTestClass.someMethod(eq(context))).thenReturn(someValue);

Проблема в том, что Matchers.eq означает , а не , что соответствует «не расширенным» версиям MyContext. Поэтому, когда someMethod вызывается во время теста с "обычным" экземпляром MyContext, который на самом деле equals является значением, используемым для context, метод-заглушка не вызывается.

Кажется, что расширенный класс MyContext в Mockito реализует собственный метод equals, по крайней мере метод equals из MyContext никогда не вызывается. Таким образом, в настоящее время я не могу придумать, каким образом можно изменить реальное сравнение.

Я могу подумать о различных обходных путях для этой проблемы, таких как использование настраиваемого сопоставления аргументов или создание метода с экземпляром «реального» объекта. Мне, однако, было интересно: есть ли какое-нибудь решение от Mockito для проверки равенства расширенных классов с их обычными аналогами?

1 Ответ

0 голосов
/ 14 ноября 2018

Это концептуально неверно: идея equals() в Java заключается в том, чтобы быть симметричной : когда a.equals(b), тогда вам лучше обнаружить, что b.equals(a) тоже!

И вв вашем случае у a есть класс MyContext, а у b есть Wh whatMockitoSpyDoesToMyContext.Таким образом, даже когда equals() сгенерированного mockito сработает, скорее всего, наоборот, эта «базовая» равна может вернуть false (потому что исходный класс MyContext ничего не знает о потенциальных подклассах, подобных тому, что здесь делает Mockito).

Я согласен, что может быть удобным, чтобы ваш пример удался, но я просто не знаю, как "правильно" туда добраться.С этой точки зрения вам действительно нужно использовать ArgumentMatcher.

Помимо этого: серьезно подумайте, действительно ли вы что-то получаете, используя eq() в первую очередь.Если эта проверка является «ядром» вашего теста, то, конечно, как-то лучше искать четкие способы проведения этой проверки.Но если это скорее побочный продукт: просто используйте вместо него any().

Значение: не усложняйте свои тесты * на 1022 * больше , чем необходимо.Обычно вы настраиваете вещи для одного конкретного случая в любом случае.Вам нужно беспокоиться о вещах, переданных someMethod(), только если ваш тестируемый код действительно может правильно передать различные объекты этому методу.

...