Управляемые данными модульные тесты

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

И конечно, никогда не тестируйте против своей живой базы данных! Но это само собой разумеется :)

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

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

Можно очистить и заполнить базу данных с инструментами (DBUnit, DBUnit.NET, другие) или просто сделать собственные служебные классы, чтобы сделать то же самое.

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

Одна вещь, которую я сделал, была, создают статические методы, которые возвратили данные тестирования известного состояния. Я затем использовал бы "поддельный" DAL для возврата этих данных, как будто я на самом деле называл базу данных. Что касается тестирования sql/stored процедуры, я протестировал его с помощью Studio управления SQL. YMMV!