Подтвердить что ты не робот

Единичное тестирование приложения, управляемого с помощью Hibernate?

Это может быть наивный вопрос, но я новичок в структурах junit и hibernate, и мне было интересно, как лучше всего пройти тестирование модулей приложения, которое в основном вызывает спящий режим, или если это даже необходимо для Сделай так?

Какая здесь самая лучшая практика?

EDIT:
Spring кажется большим предложением здесь. К сожалению, это может быть слишком много, чтобы откусить один проект. Junit, Hibernate и Spring для меня все новые, и пока все технологии, которые я хочу получить под своим поясом, я думаю, что попытка включить их всех в один проект может быть слишком подавляющим для меня.

Приветствуются ссылки на учебные пособия и/или предложения по бронированию.

4b9b3361

ОТВЕТЫ

Ответ 1

Имейте в виду разницу между модульным тестированием и интеграционным тестированием.

Модульные тесты должны тестировать код без каких-либо внешних зависимостей. Эти зависимости издеваются с использованием структуры, например, JMock.

Интеграционные тесты также важны, но основным их недостатком является то, что они занимают много времени. Вы можете запустить тысячи настоящих модульных тестов за пару секунд, но это не то же самое с интеграционными тестами.

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

Я сам написал приложение, которое тестировало веб-сайт (с помощью Spring MVC это легко) и слоев службы, а также объектов домена. Но я оставил только DAO, потому что я не хотел писать кучу медленных интеграционных тестов. Если бы у меня было больше людей на персонале, я бы тоже пошел на интеграционные тесты, но в этом случае я не чувствовал, что потраченное время будет стоить того.

Ответ 2

Что касается лучших практик:

используйте встроенную базу данных для запуска ваших тестов, если это возможно, так что вам не нужна полная развернутая реляционная база данных для запуска ваших тестов (локально или на вашем сервере непрерывной сборки, если таковой имеется). Таким образом, вам также не нужно (обязательно) беспокоиться о откате и т.д., Вы можете просто воссоздать базу данных, когда вам нужно. Тестирование со встроенной базой данных не проверяет особенности, которые могут возникнуть при использовании вашей конкретной производственной базы данных, но она проверяет ваш код, что должно быть достаточно.

Вы также можете использовать DbUnit, расширение для JUnit, чтобы легко заполнить базу данных ожидаемыми строками и поместить ее в известную перед тем, как запустить тесты Hibernate.

Ответ 3

Лучшая практика? Я использую Spring и делаю все мои тесты транзакционными. Я выполняю тест и откатываю все изменения, поэтому я не изменяю состояние базы данных.

Ответ 4

Мне нравится использовать в памяти hsqldb для тестирования. Процесс для каждого спящего POJO:

  • Создайте объект
  • Сохраняйте его в DB
  • Очистить сеанс
  • Получить его из базы данных
  • Утвердить, что объекты равны.

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

Ответ 5

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

Вы также можете посмотреть CaveatEmptor, который образец приложения разработал для книги "Сохранение Java с Hibernate"

Ответ 6

Напишите простой слой, который передает запросы в Hibernate. Затем используйте насмешливую библиотеку, например EasyMock или JMock, чтобы утверждать, что ваш уровень шпиля Hibernate правильно вызывается вашими классами приложений. Это хорошо описано в частично завершенной книге JMock (прокрутите вниз до тестового запаха "все издевается" ).

Ответ 7

Если вы используете Hibernate для богатых доменов моделей, модульная логика домена так же проста, как тестирование POJO и Hibernate не мешает вам. Единственное предостережение здесь: для двунаправленных сопоставлений вам может потребоваться установить объект с обеих сторон для модульных тестов.

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

Ответ 8

Конечно, вы бы unit test ваш уровень стойкости, если он не был написан в Hibernate, не так ли?

Создайте заданный интерфейс персистентности, который реализован с использованием Hibernate, создайте экземпляр некоторых объектов образца, выполните операции CRUD и попросите JUnit утверждать, что операции были успешными. То же, что и любой другой класс.

Ответ 9

Вы можете использовать Spring, чтобы помочь здесь.

Он имеет отличную структуру unit test, вы можете использовать его для проверки операций CRUD, а затем изменений отката - отлично, если у вас нет возможности перезагружать базу данных каждый раз.

Ответ 10

Два случая легко проверить:

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

  • Для функций, которые сохраняются только в базе данных без их чтения, вы можете не сохранять при тестировании.

Самый простой (самый грубый) способ сделать # 2 - добавить параметр reallyUpdate к функции, а затем окружить каждый вызов "сохранить" с помощью:

if (reallyUpdate) {
    HibernateUtil.saveOrUpdate(theThing);
}

Для меня это были самые низкие висячие плоды.