Я пишу некоторые интеграционные тесты в JUnit. Здесь происходит то, что когда я запускаю все тесты вместе подряд (а не по отдельности), данные, сохраняемые в базе данных, всегда изменяются, и тесты обнаруживают неожиданные данные (вставленные предыдущим тестом) во время их выполнения.
Я думал использовать DbUnit, но мне интересно, сбрасывает ли он индекс автоинкремента между каждым выполнением или нет (потому что тесты также проверяют идентификаторы сохраняемых сущностей).
Спасибо
M.
Рекомендуется перевести базу данных в известное состояние перед выполнением теста, и DBUnit предоставляет для этого все необходимое. Но не полагайтесь на автоматически увеличивающиеся столбцы, поместите их также в свой набор данных DBUnit. Плюсы: вы можете вручную проверить состояние базы данных после выполнения теста, который не прошел. Минусы: вам нужно настроить и поддерживать наборы данных.
Другой подход состоит в том, чтобы запускать каждый тестовый метод внутри транзакции (и откатывать транзакцию в конце выполнения). Плюсы: данные легче настраивать и поддерживать (в базе данных). Минусы: исправлять неудачный тест менее удобно.
Вы можете запускать отдельные тесты или, если применимо, группы тестов как одну транзакцию, а затем выполнять откат в конце. (Это может быть сложно, если сами тесты содержат несколько транзакций, а ваша БД не поддерживает вложенные транзакции или точки сохранения.)
В качестве альтернативы создайте тестовую базу данных с помощью скриптов. Здесь может помочь DbUnit, а также другие генераторы баз данных, такие как LiquiBase, dbmaintain, dbmigrate Затем вы можете удалить всю базу данных и создать ее заново для каждого теста или группы тестов. Полезность этого подхода уменьшается по мере того, как набор тестовых данных становится большим, а накладные расходы возрастают.
Последний вариант — не заставлять ваши тесты зависеть от сгенерированного идентификатора, поскольку в зависимости от сгенерированного значения будут создаваться хрупкие тесты. Полезно проверить сгенерированный идентификатор, поэтому проверьте эти значения для некоторых тестов, но я не уверен, что есть смысл тестировать идентификаторы для всех тестов.
РЕДАКТИРОВАТЬ: ОП спросил об использовании спящего режима для воссоздания схемы. Это можно сделать, создав новый SessionFactory для каждого теста и установив для параметра «hibernate.hbm2ddl.auto» значение «true» при создании SessionFactory. Я упоминаю о снижении эффективности drop-create — это относится и к этому случаю.
Плохо полагаться на значения идентификатора в тесте, потому что автоинкремент зависит только от базы данных. Поэтому я бы никогда не стал проверять идентификаторы, потому что, если вы это сделаете, ваш тест зависит от того, заполнены ли объекты определенными значениями идентификаторов, что не является примером из реальной жизни. Тест не должен зависеть от идентификаторов автоинкремента.
По существу этот вопрос может быть решен двумя путями.
Оберните тесты, связанные с БД, в транзакцию. Перед проверкой начните транзакцию. После завершения тестового прогона прервать транзакцию всегда прерывать транзакцию. Таким образом, никакие изменения, сделанные в тесте, не будут сохранены.
Используйте что-то вроде DBUnit и т. Д., Чтобы имитировать классы, связанные с операциями БД, чтобы никакие данные никогда не поступали в БД, а ваши классы возвращали результаты, как если бы операция БД была выполнена.
Если вы получаете доступ к БД при выполнении тестов, я предпочитаю подход 1.
