Как использовать JUnit и Быть в спящем режиме полезно?

Вы можете использовать DBUnit для тестирования уровня DAO. Потому что вам нужны данные для тестирования.
Пример: DBUnit xml вставит фиктивные данные в описанную вами базу данных, а затем вы можете вызвать assertEquals ("myname", userDAO.findById (1) .getName ()); и т.п. После проверки вы можете удалить фиктивные данные с помощью DBUnit . Проверьте деталь .

Документы
Тестирование гибернации с помощью dbunit
DBUnit и Hibernate

Я использую подход Криса Ричардсона, описанный в POJO в книге действий

База данных SQL в памяти

Плюсы

• Нет сетевого трафика
• Нет доступа к диску
• Полезно для тестирования запросов

Минусы

• Похожа ли его схема на схему производственной базы данных?

Именованные запросы

Плюсы

• Могут храниться отдельно от репозитория, что позволяет вам тестировать его без репозиториев

Минусы

• Не работает нормально при использовании динамических запросов

Мок-репозитории

Плюсы

• Уменьшает доступ к базе данных
• Уменьшает количество тестовых примеров

Минусы

• Требуется тестировать запросы к отдельно база данных

DBUnit

Плюсы

• Это расширение jUnit

Минусы

• Вам необходимо создать файл XML, содержащий ожидаемые значения
• Если вы пропустите новое сопоставленное свойство, возможны ошибки

с уважением,

Вы можете использовать несколько подходов, в зависимости от вашего сценария

• использовать встроенную базу данных (HSQLDB) для ваших модульных тестов. Вставьте все требуемые данные в @Before и удалите в @After . Однако это не совсем «модульный» тест, потому что он зависит от некоторых внешних предварительных условий.
• вы можете имитировать свой dao (например, используя Mokcito), чтобы он не мешал работе с базой данных. Это может быть полезно при тестировании уровня обслуживания, и вам все равно, что хранится в базе данных.

Хорошо, несколько очков.
Прежде всего, , если вы должны протестировать реальный код, который общается с БД , используйте DBUnit для облегчения вашей жизни, и рекомендуется использовать HSQLDB, чтобы ваши тесты могли настроить свою среду во время выполнения, не требуя, чтобы база данных уже была установлена ​​и настроена.

Во-вторых, если вам не нужно разговаривать с БД , я бы использовал общую имитационную библиотеку (будь то EasyMock, JMock или Mockito, например), и сделать так, чтобы тесты не взаимодействовали с БД, что обычно делает тесты быстрее и проще.

Лично я очень осторожно отношусь к использованию встроенных баз данных, таких как HSQLDB с Hibernate, и ожидаю, что все будет работать точно так же, когда вы переместите его на сервер Oracle / MySQL / SQL. Hibernate - слишком неплотная абстракция для этого.

У меня нет опыта работы с другими средами, кроме JUnit. Я считаю, что он очень хорошо справляется со своей задачей. Вот некоторые вещи, которые я всегда помню:

• Модульные тесты для операций CRUD базы данных никогда не должны предполагать наличие или отсутствие определенных данных. Все, что вставлено, также должно быть удалено или откатано.
• Не забудьте очистить базовый объект соединения. Это фактически выполнит кэшированные операторы и активирует любые триггеры в модели данных.