Nhibernate Nunit - очистить базу данных между тестовыми сценариями - PullRequest
2 голосов
/ 16 ноября 2010

У нас довольно обширный набор тестов, который выполняется вечно. После завершения каждого теста базу данных (MSSQL) необходимо очистить, чтобы она была новой для следующего тестового примера. Мы делаем это путем временного удаления всех внешних ключей, TRUNCATE'ов всех таблиц и повторного добавления FK.

Этот шаг занимает где-то 2-3 секунды, согласно NHProfiler. Кажется, все время тратится на операции ФК.

Наш нынешний метод явно не оптимален, но каким путем мы должны пойти, чтобы улучшить производительность? Количество элементов, которые фактически удаляются из БД, совершенно незначительно по сравнению с количеством операций для удаления / добавления FK.

Использование базы данных SQLite в памяти не вариант, так как тестируемый код использует специфичные для MSSQL операции.

Ответы [ 4 ]

0 голосов
/ 16 ноября 2010

В прошлом я сделал несколько вещей, чтобы ускорить тестирование интеграции баз данных. Первое, что я сделал, это то, что у меня появился скрипт sql, который фактически создает всю базу данных с нуля. Этого легко добиться, используя такой инструмент, как Red-Gate SQL Compare для пустой базы данных.

Во-вторых, я создал скрипт, который удалил все объекты базы данных из существующей базы данных.

Тогда мне нужен был скрипт, который заполнял базу данных тестовыми данными. Опять же, просто создать с помощью инструментов Red-Gate. Вам не нужно / не нужно тонны данных здесь, просто достаточно, чтобы покрыть ваши тестовые случаи.

С этими элементами я создал один тестовый класс со всеми моими операциями только для чтения. В начале этого класса я очистил локальный экземпляр SQL Server Express, запустил скрипт create, а затем запустил скрипт populate. Это обеспечило правильную инициализацию базы данных для всех тестов только для чтения.

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

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

0 голосов
/ 16 ноября 2010

Что касается использования SQL Server Compact, создайте базу данных из файлов сопоставления, используя схему nhibernate, создайте и загрузите данные для каждого теста. если вы говорите о тривиальной сумме данных.

Посмотрите этот пост в блоге - Использование SQL Server Compact Edition для модульного тестирования

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

0 голосов
/ 16 ноября 2010

Почему вы даже используете БД в своих тестах?Конечно, вы должны издеваться над механизмом персистентности?Если вы на самом деле не пытаетесь протестировать ту часть функциональности, вы тратите время и ресурсы на вставку / обновление / удаление данных.

Тот факт, что ваши тесты основаны на специфике ms sql и возвращаемых данных, указывает на вероятность того, что вашей архитектуре нужно на это взглянуть.

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

w: //

0 голосов
/ 16 ноября 2010

Вы можете обернуть все в транзакции и в итоге просто откатить все.Вот как я это делаю.Это позволяет также запускать тесты параллельно.

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