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

Question

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

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

Моя стратегия юнит-тестирования такова:

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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