JUnit для кода базы данных

Question

Я пытался реализовать модульное тестирование, и в настоящее время у меня есть код, который делает следующее:

1. Запросить внешнюю базу данных, загрузка в таблицу подачи
2. Запросите представление, которое представляет собой дельту моих таблиц подачи и данных, обновление таблицы данных в соответствии с таблицей подачи.

моя стратегия модульного тестирования такова:

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

1. в setUP() загрузите некоторые данные в мою тестовую базу данных
2. запустите мой код, используя мою тестовую базу данных в качестве источника
3. проверить таблицу данных, проверив количество и наличие/отсутствие определенных записей
4. очистить тестовую базу данных, загрузить другой набор данных
5. запустить код еще раз
6. еще раз проверьте таблицу данных

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

Кажется, это немного громоздко и должен быть более простой способ?какие-либо предложения?

Answer 1

Вы намерены протестировать представление, генерирующее дельты, или проверить, что ваш код правильно добавляет, удаляет и обновляет в ответ на представление?

Если вы хотите протестировать представление, вы можете использовать такой инструмент, как ДБУнит чтобы заполнить ваш фид и таблицы данных различными данными, дельту которых вы рассчитали вручную.Затем для каждого теста вы должны убедиться, что представление возвращает соответствующий набор.

Если вы хотите проверить, как ваш код реагирует на различия, обнаруженные представлением, я бы попытался абстрагироваться от доступа к базе данных.Я представляю себе метод Java, которому вы можете передать набор результатов (или список POJO/DTO) и вернуть список массивов объектов параметров (опять же или POJO), которые нужно добавить.Другие методы будут анализировать список различий на предмет элементов, которые нужно удалить и обновить.Затем вы можете создать макет набора результатов или pojo, передать их в свой код и убедиться, что возвращаются правильные параметры.И все это без вмешательства в базу данных.

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

Answer 2

ДбЮнит удовлетворит ваши потребности.Следует обратить внимание на то, что они перешли на использование SLF4J в качестве фасада журналирования вместо JCL.Вы можете настроить SLF4J для пересылки журналов в JCL, но будьте осторожны, если вы используете Maven, DbUnit по умолчанию засасывает их поставщика журналов Nop, поэтому вам придется использовать исключение, я в блоге об этом конфликте недавно.

Answer 3

Я использую DbUnit, но также очень много работаю, чтобы не проводить тестирование на базе БД.Тесты, противоречащие базе данных, должны существовать только с целью тестирования интерфейса базы данных.Итак, у меня есть Mock Db Connections, с помощью которого я могу установить данные для использования во всех остальных моих тестах.

Answer 4

Помимо уже предложенного DBUnit, вы можете изучить Единицы.Он использует DBUnit, но предоставляет больше (цитата с сайта):

• Автоматическое обслуживание баз данных, при поддержке инкрементных, повторяемых и пост -обработки сценариев
• Автоматически отключать ограничения и устанавливать минимальное значение для последовательностей.
• Поддержка Oracle, Hsqldb, MySql, DB2, Postgresql, MsSql и Derby.
• Упрощение настройки подключения к тестовой базе данных
• Простая вставка тестовых данных с помощью DBUnit * Запуск тестов в транзакции
• Создание и инъекция управляющего объектами JPA для Hibernate, Toplink и * Hibernate SessionFactory создание и сеанс
• Автоматически тестирование отображения объектов JPA / Hibernate сопоставленных объектов с базой данных

Answer 5

Если вы используете Maven, один из вариантов — использовать sql-maven-плагин.Он позволяет запускать сценарии инициализации/заполнения базы данных во время цикла сборки maven.