6.1 Подигравка на статичния метод mockStatic()
И още един важен момент е подигравката и проверката на статичните методи. „Какво лошо има в това?“, питате вие. Да, статично, но методите са същите. И ще сгрешите.
Помните ли откъде започнахме да учим за фалшивите обекти? Тъй като тези обекти са изкуствено създадени чрез DynamicProxy
. А статичните методи не са обвързани с ниHowви обекти и DynamicProxy
е невъзможно да се прихванат извиквания към тях чрез . Това е всичко.
Но създателите на Mockito успяха да се измъкнат и тук - те написаха свой собствен инструмент за зареждане на класове и с негова помощ успяха да заменят класове в движение. Голяма и трудна работа, но все пак успяха да я свършат.
Ще трябва да добавите допълнителна библиотека към pom.xml
:
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-inline</artifactId>
<version>4.2.0</version>
<scope>test</scope>
</dependency>
Ето How да работите, ако трябва да имитирате статичен метод.
1 Създайте специален обект на макет клас:
MockedStatic<ClassName>managerObject = Mockito.mockStatic(ClassName.class);
2 Добавете правила за работа към този обект:
Към този обект на правилото е необходимо да се придържаме по други начини.
managerObject.when(ClassName::method name).thenReturn(result);
3 Не забравяйте да обвиете използването на този обект,try-with-resources
така че обектът да бъде незабавно изтрит и Mockito да може да изчисти правилата, свързани с него.
Пример:
@Test
void givenStaticMethodWithNoArgs () {
try (MockedStatic< StaticUtils> utilities = Mockito.mockStatic( StaticUtils.class)) {
// add rule
utilities.when(StaticUtils::name).thenReturn("Hello");
// check if the rule works
assertEquals("Hello", StaticUtils.name());
}
}
Не толкова красиво, колкото с анотации @Mock
и @Spy
, но много практично. Беше много трудно да се пишат тестове, когато беше невъзможно да се подиграва прост статичен метод, който беше използван вътре в тестваните методи.
GO TO FULL VERSION