.NET - модульное тестирование вашего кода и состояния в вашей базе данных

Question

Допущения: мы используем .NET-кодирование для SQL Server 2005

Мне было просто интересно, как большинство людей включают состояние в модульные тесты, которые влияют на их базу данных? Я знаю, когда и где использовать насмешки, но когда вы хотите пройти мимо этого и на самом деле сделать несколько тестов базы данных ... какие стратегии вы используете для настройки и разрушения вашей базы данных? Вы делаете это за тест? или настройте определенный сценарий в базе данных и проведите несколько тестов против этого «состояния мира». Любой совет поможет. Спасибо.

Answer 1

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

Answer 2

Прежде всего, все мои «сценарии» DDL базы данных написаны на классах C #. Для этого я использую Migrator.NET: у меня есть несколько классов, где каждый класс содержит некоторую логику для обновления или понижения моей БД.

У меня есть база данных с именем 'projectname_test', которую я использую для запуска своих юнит-тестов, для которых требуется доступ к БД. Эта БД обновляется моими классами Migrator.NET. Эта БД обновляется процессом CI (CC.NET).

Юнит-тесты, которые обращаются к этой БД, удаляют все, что находится в этой БД, после их запуска. И, когда я хочу сыграть в нее радикально, я могу просто оставить свою тестовую базу данных; он будет восстановлен процессом CC.NET. :)

Answer 3

Вот что я делаю в NUnit ... Запустите транзакцию базы данных методом, помеченным атрибутом [Setup]. Настройте состояние базы данных, как вы хотите. Затем NUnit запускает тест для этого состояния. Откатите транзакцию базы данных методом, отмеченным атрибутом [TearDown]. Вы никогда не измените состояние базы данных таким образом.

Answer 4

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

Answer 5

Посмотрите на этот вопрос и ответы Как проверить код, связанный с базой данных, с помощью NUnit?

Answer 6

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

1. Новый путь установки - При создании БД с нуля
   • Автоматизация создания БД с использованием MsBuild и SQLCMD, передача параметров в
   • Использование PowerShell для любых административных задач на уровне сервера
2. Путь обновления - При обновлении БД существующего клиента
   • Восстановление резервной копии очищенной БД реального мира в качестве базовой линии
   • Если обязательно применить обновления после обновлений
   • Снова используйте PowerShell, MsBuild, SQLCMD для организации жгута

Для меня, даже когда модульное тестирование, мне нравится тестировать с данными «реального мира», особенно с объемом данных реального мира, чтобы как можно раньше выявить проблемы, приближенные к этапу реализации . Так что, в общем, я даже не провожу Mock Testing и не использую лучший модуль для тестирования модулей, который можно перестроить и запустить по требованию. В основном, подход непрерывной интеграции или частичный CI (оксюморон).

Обратите внимание, что если вы используете подход непрерывной интеграции, то, что вы помните, даже во время внедрения и разработки, это автоматизация развертывания результатов / выпуска в производство. По сути, помните End с самого начала, потому что ваша новая функция ничего не стоит, если ее нелегко развернуть. Это особенно актуально в том случае, когда горизонтальная масштабируемость Big Data сегодня обычно означает, что вы разделяете клиентов в разных БД и вам приходится многократно запускать сценарии развертывания на нескольких из этих БД предсказуемым образом.

Сколько раз Разработчик объявлял, что они "сделали" , но тогда вы не представляете, как даже начать выполнять функциональное тестирование на нем, потому что его нельзя развернуть в любом месте, кроме Среда разработчика.

Таким образом, проводка модульного тестирования, которую вы создаете, действительно проверяет не только ваш код, но и сценарии развертывания. В общем, для достижения этого я использую Jenkins, MsBuild, PowerShell. И если задействованы браузеры, я использую VirtualBox для виртуальной машины для запуска различных браузеров.