#java #junit #mockito
#java #junit #mockito
Вопрос:
Итак, у меня есть этот класс (используется lombok):
@RequiredArgsConstructor
@Service
public class ServiceImpl {
private final BookService bookService;
@Autowired
private TableService tableService;
public void method() {
if (!bookService.isEmpty()) return;
Object table = tableService.getObject();
}
}
Мой тестовый класс:
@ExtendWith(MockitoExtension.class)
@RunWith(JUnitPlatform.class)
public class ServiceImplTest {
@Mock BookService bookService;
@Mock TableService tableService;
@InjectMocks ServiceImpl serviceImpl;
@Test
public void testMethod() {
when(bookService.isEmpty()).thenReturn(true);
when(tableService.isEmpty()).thenReturn(new Object());
serviceImpl.method();
}
}
Если я его запускаю, значение bookService
равно нулю. Он не вводится в класс. Когда код находится в if (!bookService.isEmpty()) return;
bookService
нулевом состоянии.
если я изменю свой testMethod
на этот:
@Test
public void testMethod() {
MockitoAnnotations.initMocks(this);
when(bookService.isEmpty()).thenReturn(true);
when(tableService.isEmpty()).thenReturn(new Object());
serviceImpl.method();
}
Итак, я добавил MockitoAnnotations.initMocks(this);
, что код Object table = tableService.getObject();
в моем классе возвращает null. Таким tableService
образом, значение не равно null, а getObject()
возвращает значение null;
Есть идеи, как это исправить? Мне не разрешено изменять код класса.
Заранее спасибо.
Комментарии:
1. » Есть идеи, как это исправить? — Не используйте инъекцию поля, вместо этого используйте инъекцию конструктора. — » Мне не разрешено изменять код класса». — В этом случае нужно было бы перейти к ручному отражению, что я крайне не рекомендую. Было бы намного проще переключиться с внедрения поля на конструктор.
2. Да… Я бы хотел… Но компания попросила мою компанию сделать покрытие кода, не хочет, чтобы мы меняли код…
3. В этом случае я бы поговорил с владельцем продукта, объяснил ситуацию и подчеркнул, что «исправление» (для данного конкретного случая) займет 10 минут, тогда как обходной путь (рефлексивный доступ) займет около половины дня, и его нелегко понять и поддерживать. Если владелец продукта все еще хочет продолжить рефлексивный путь, тогда сделайте это. Я бы также подчеркнул, что » написание тестов с единственной целью покрытия » довольно бессмысленно и что должны быть разрешены некоторые корректировки для повышения тестируемости.