Junit test бизнес-класс, который вызывает класс Dao

Question

Я использую продукт, который реализован с использованием Struts и простой инфраструктуры JDBC. Я планирую реализовать тестирование Junit в проекте, чтобы ускорить тестирование. FYI, проект еще не готов к производству. Это все еще находится в стадии разработки, но использует очень старые технологии. Проект не имеет интерфейса и соответствующей реализации. Старое программирование вроде, класс напрямую создается и используется как таковой. Таким образом, нельзя использовать mockito framework. При всех этих ограничениях мне нужно разработать TDD в проекте. Я не могу полностью отказаться от него и разработать его с использованием новых технологий.

Мой вопрос: я пишу тест junit для бизнес-уровня, чтобы проверить, работает ли этот метод или нет. Этот бизнес-класс также обращается к DAO. Поскольку соединение БД не создано во время теста, оно дает ошибку подключения. Как написать тест junit для тестирования только бизнес-уровня? Должен ли я включать DAO-соединения в метод тестирования? Если да, как мне это достичь?

Я новичок в Junit и TDD. Поэтому, пожалуйста, направляйте меня, если мое понимание ошибочно или исправить это.

Answer 1

Предлагаю реорганизовать проверяемое состояние, прежде чем делать что-либо еще. Если дизайн действительно сломан, как вы сказали, теперь есть способ написать полезный Тест для определенного класса.

Answer 2

Не могли бы вы реорганизовать свои коды? Если это так, вы можете начать с реорганизации своего кода, чтобы определить интерфейсы DAO для ваших реальных DAO, реализовать макетную версию вновь созданных интерфейсов и внедрить их в свои службы в модульном тесте.

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

public class YourService { 
    private final YourDAOInterface dao; 

    public YourService(YourDAOInterface dao) { 
     this.dao = dao; 
    } 
} 

Здесь параметр конструктора dao может быть реальным DAO или фиктивной реализацией для тестирования (вы должны сделать эти двух DAO реализовать тот же интерфейс YourDAOInterface).

Answer 3

Я думаю, первый абзац вашей статьи не связан с вопросом, который вы в конце концов спросили во втором абзаце.

Мы называем это модульным тестированием по какой-либо причине - потому что мы тестируем только единицу - это не интеграционный тест. Здесь мы не смешиваем слои.

Если ваша цель - проверить только бизнес-уровень - вы проверяете только бизнес-уровень, и вы издеваетесь над всем ниже (например, DAO и т. Д.). Поэтому предоставьте данные в код вашего бизнес-уровня, используя некоторую насмешливую структуру (Mockito, PowerMock, JMockit и т. Д.) И предположите, что ваш уровень DAO верен.

Используя фальшивые фреймворки, вы предоставляете те же данные бизнес-функции, что слой DAO должен передаваться из базы данных, и вы вообще не выполняете слой DAO. Вам понадобятся эти издевательские API-интерфейсы в дополнение к JUnit для правильной записи модульных тестов.

Комментарий к вопросу о использовании базы данных и фреймворка памяти (Apache DBUnit и H2 DB есть), но вам понадобятся те, которые при написании модульных тестов для уровня DAO, а не для бизнес-уровня.

Как и в других ответах, всегда рекомендуется рефакторинг и проверка кода.

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