Ложный класс зависимостей по сути нулевой? - PullRequest
Новая
       12

Ложный класс зависимостей по сути нулевой?

0 голосов
/ 20 октября 2018

Как новичок в Mockito Junit, это может звучать очень дамп, но я все же хотел бы подтвердить: 

Class1 input1;

@Mock
Class2 input2;

private Class3 obj;

@Before
public void setup() {
    this obj = new Class3(input1, input2);
}

@Test
public void doTest() {
     val result1 = obj.method1(input1); // return sth.
     val result2 = obj.method2(input2); // return null.
}

Таким образом, input1 и input2 передаются в объект Class3, но только input2 является Mockedзависимость.Затем я обнаружил, что когда я вызываю method2, который опирается на input2, он просто возвращает null.

То есть, какой из насмехающихся классов по сути нулевой?Вот почему мы должны использовать когда ... thenReturn для издевательства над классом?В конце концов, наша цель - протестировать основную функцию, но не зависимость.

Правильно ли мое понимание?

Ответы [ 2 ]

0 голосов
/ 21 октября 2018

Насмешенный класс не является нулевым.Это скелет с той же сигнатурой, что и у исходного класса, но без реализации.Инструментарий «видит» вызовы всех методов, поэтому его можно проверить позже.Для этого имитируется объект, который не работает.Он не может хранить данные и не может выполнять методы.Вы можете контролировать только все вызовы и все возвращаемые значения макета.Если вам нужны более продвинутые макеты, вы должны использовать @Spy.Шпион - это «фиктивный», но с оригинальной реализацией: это инструментальный класс для обнаружения всех вызовов к нему и управления выводом, НО также имеет оригинальные средства хранения и реальные вызовы.

Другой способ выполнения реальных вызовов заключается в следующем: Mockito.when(myMockedObject).thenCallRealMethod();

В модульном тестировании рекомендуется проверять ТОЛЬКО один класс, который вы тестируете, без базовых классов.Звучит как открытая дверь, но на самом деле это не так.Все классы, используемые классом, который вы тестируете, должны быть проверены.С макетом у вас есть полный контроль над возвращаемыми значениями, и вы можете проверить все угловые случаи для этого класса.Все классы, которые подвергаются проверке, должны быть проверены самими своими юнит-тестами.Это приводит к следующей проблеме: все используемые классы должны быть введены или изменены тестом.Вместо реального драйвера БД вы хотите иметь возможность вводить макет, чтобы вы могли видеть, все ли правильные вызовы сделаны.

0 голосов
/ 20 октября 2018

Да, ваше понимание правильное.

Если вы использовали соответствующий бегун (junit4) или расширение (junit5), ваш смоделированный объект не равен нулю (даже если его метод toString может возвращать что-то похожее"null").

Однако проблема может заключаться в том, что ваш Class3#method2 использует метод макета Class2, который возвращает ноль.

На самом деле такое поведениеразыскиваетсяЗдесь у вас есть выбор между:

  • сделать ваш макет возврата глубокие заглушки , используя аннотацию @Mock (answer = Answers.RETURNS_DEEP_STUBS), таким образом, любой метод Class2 (который не являетсяfinal или возвращение типа примитива или оболочки) возвращает макет, и любой метод этого макета возвращает макет и т. д.

  • явно объявляет, как макет должен вести себя с чем-то вроде: Mockito.when(input2.myMethod()).thenReturn("test");.API subbing, предоставленный Mockito, хорошо документирован: https://static.javadoc.io/org.mockito/mockito-core/2.23.0/org/mockito/Mockito.html#stubbing

Надеюсь, это поможет,

...