СУБД в памяти для модульного тестирования

Question

Я ищу удовлетворительные варианты для модульного тестирования моих классов .NET DAL; Так как они являются классами DAL, они обращаются к базе данных напрямую, используя ADO.NET. В настоящее время я использую экземпляр базы данных MSSQL для тестирования, но мне было интересно, какие существуют более быстрые варианты - поскольку модульные тесты должны выполняться как можно быстрее, решение в памяти было бы идеальным.

Я должен также упомянуть, что я привязал себя к TSQL, поскольку я только собираюсь использовать платформу Microsoft.

Answer 1

Учитывая, что вы заявляете:

Я должен также упомянуть, что я связал себя в TSQL, так как я только когда-либо собираюсь использовать Microsoft платформы.

Тогда использование SqlServer compact Edition может хорошо подойти для ваших нужд. Он не будет работать полностью в памяти, но может работать в режиме «только чтение» (когда в основной файл базы данных не вносятся изменения, поэтому он может использоваться несколькими тестами одновременно)

Существует несколько ошибок, хранимые процедуры не поддерживаются, необходимо преобразовать несколько типов данных, а определенные типы данных имеют жесткие ограничения (особенно varchar, который может содержать только 4000 символов). Linq to Sql также не поддерживается должным образом.

Тем не менее, я использовал SqlServer Compact Edition в качестве почти полной замены правильной базы данных Sql Server с хорошими результатами.

Answer 2

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

Конечно, @TopBanana прав насчет некоторых проблем, связанных с неиспользованием «реальной» базы данных. Тем не менее, СУБД в оперативной памяти идеально подходит для тех видов тестов, которые вы хотите выполнить очень быстро (например, тесты регистрации для инкрементных сборок или сборок CI).

Другим огромным преимуществом является то, что вам не нужно беспокоиться о настройке или сносе. Провалить регистрацию не получится, потому что разработчик А сломал вашу базу данных разработчика; -)

Answer 3

У меня были похожие проблемы с Oracle, и мы сделали следующее:

• удостоверился, что у нас реальные юнит-тесты не касаются БД, но вместо этого использовал mocks для сервисов

• Тесты с тегами БД, которые на самом деле нуждались в Oracle, по сравнению с тестами, которые могли бы работать с HSQLDB или H2 или любым другим в базе данных памяти. Таким образом, мы можем запустить их отдельно.

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

Это значительно ускорило тестирование.

Answer 4

Я слышал, что есть программа для монтирования ramdisk в windows (не помню URL, извините)

Может быть интересно создать тестовые базы данных на этом.

Answer 5

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

Если вы посмотрите на действительно большой набор модульных тестов для NHibernate, вы увидите, что он использует SQL Server (на основе дисков), и тесты работают на удивление быстро. Еще более впечатляет тот факт, что создание / удаление таблиц происходит гораздо чаще, чем средний набор модульных тестов, а это не то, для чего оптимизирован SQL Server.

Answer 6

Является ли SQL Server действительно узким местом для ваших модульных тестов?

Я имею в виду:

1. Профилировали ли вы свои модульные тесты (с чем-то вроде SQL Profiler). Они все медленные? Несколько медленных? Почему?
2. Ваши юнит-тесты делают слишком много? Код установки и разрыва слишком тяжел?
3. Если SQL является вашим узким местом, рассматривали ли вы фальшивый фреймворк , поэтому вы исключаете все ваши вызовы SQL.