Как использовать JUnit и Hibernate?

Question

Я хочу использовать JUnit для проверки кода Hibernate, такого как вставка, обновление, удаление, .. метод и управление транзакциями.

Но я не знаю, как применять единичный тест для спящего режима, и что я должен проверить с помощью Hibernate.

Как проверить методы DAO?

Надеюсь, что вы могли бы дать мне несколько руководств!

Answer 1

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

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

Answer 2

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

Документы
Hibernate testing with dbunit
DBUnit and Hibernate

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

В памяти базы данных SQL

Pros

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

Против

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

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

Pros

• Может храниться отдельно от хранилища, который позволяет проверить его без репозиториев

Cons

• не работает нормально при использовании Dinamic запросов

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

Pros

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

Cons

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

DBUnit

Pros

• Это является расширение JUnit

Cons

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

С уважением,

Answer 6

Если вы создали объект DAO , вы можете затем отправить ему некоторые объекты, вызвать сохранение, а затем получить эти объекты и проверить значения полей. Это очень простое тестирование спящего режима.

Удостоверьтесь, что вы очищаете свои данные, хотя в методах настройки или разрыва. Если вы сохраняете объекты, удалите их.

Рекомендации по использованию Rails - использовать отдельную базу данных для тестирования, заполненную тестовыми данными. Я бы не сделал этого против производственной базы данных; если у вас есть база данных разработки для себя, что вы можете легко обновить данные, просто используйте это.