У меня проблема с простой тестовой конструкцией, которую я хотел бы раз и навсегда решить.Как написать Unit Test для менеджера, запускающего dao?
Я довольно привык к регулярному шаблону проектирования Java, где есть Manager interface (или фасад) и набор DAO interfaces. Конкретная реализация ManagerImpl использует конкретные реализации DaoImpl.
Прямо сейчас я нахожусь в точке реализации, где у меня нет базы данных связано с моим проектом, поэтому я предполагаю, что это идеальное время, чтобы написать соответствующие модульные тесты без БД :-)
Я был в состоянии издеваться над некоторыми методами моего менеджера, используя mockito, но так как метод Test Under (или так называемый System Under Test) использует DAO внутри себя, мне тоже пришлось бы издеваться над DAO. К сожалению, я не могу этого сделать, не устанавливая конкретную реализацию DAO в моем менеджере, например myManager.setMyDao(mockedDao), но теперь мне придется вытащить этот метод setMyDao в интерфейс, что, конечно же, разрывает инкапсуляцию и делает мои чистые и совершенные интерфейсы похожими на мусор.
Вопрос в следующем: Как насмехаться с DAO в тестах при сохранении чистой Manager-Dao архитектуры?
+1: действительная точка на тестировании 'Impl', однако совет по избавлению от интерфейса * может * быть короткоживущим, когда оказывается, что« менеджер »является зависимостью для какого-либо другого объекта, который должен быть протестирован (хотя из-за * вид * глобальный характер, это может быть не так). –
@jimmy_keen 'Manager' всегда можно было высмеивать, а затем проверять другой код. И если что-то еще «получается», это не сложно реорганизовать. Современные IDE имеют рефакторинг «извлечения интерфейса», что делает изменение тривиальным. – kan
Думаю, я могу жить с помощью суперпоточного метода setMyDao(). Я думал, что должен тестировать интерфейсы, а не конкретные реализации (Менеджер). Наверное, я ошибся, иногда это невозможно. –