Модульные тесты MSTest и доступ к базе данных, не касаясь реальной базы данных

Question

В моем коде я взаимодействую с базой данных (не является частью моего файла решения).База данных принадлежит отдельной команде администраторов баз данных, и код, который мы пишем разработчикам, разрешен только для доступа к хранимым процессам.Однако у нас есть полное представление о процессах, таблицах и столбцах базы данных (это определение).Для моего кода, который зависит от данных, в настоящее время я пишу модульные тесты, которые выводят данные в таблицы (и разбирают / удаляют эти строки после завершения модульного теста), поэтому я могу запускать модульные тесты, чтобы проверить мой взаимодействующий кодс БД.Весь код для этого находится в тестовом файле (особенно в функциях ClassInitialize () и ClassCleanup ()).Тем не менее, я получил некоторое горе от того, что мои новые коллеги называют мой стиль модульных тестов «разрушительным», потому что я читаю / пишу в базу данных dev, вставляя и удаляя строки.В то время, когда мы кодируем модульные тесты, дизайн базы данных, как правило, нестабилен, поэтому много раз мы можем находить проблемы в хранимом коде процесса, прежде чем запускать отдел контроля качества в наших программах (экономит ресурсы).Все они говорят мне, что есть способ клонировать базу данных в память во время выполнения модульных тестов MSTest, однако они не знают, как это сделать.Я занимался исследованиями в Интернете и не могу найти способ сделать то, что от меня требуют мои коллеги.

Может кто-нибудь сказать мне наверняка, может ли это произойти в среде, которую я показал выше?Если да, можете ли вы указать мне правильное направление?

Answer 1

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

В вашем коде настройки теста :

• создать «временную» базу данных с использованием сценариев SQL.Используйте уникальное имя, например unitTestDatabase_ [timestamp].
• настроить данные, необходимые для вашего теста в базе данных тестов.В идеале, используя общедоступные функции API (например, CreateUser, AddNewCustomer), но там, где требуемый API не существует, используйте команды SQL.Использование API для настройки тестовых данных делает тесты более устойчивыми к изменениям низкоуровневой реализации (т. Е. Схемы базы данных).Именно поэтому мы пишем модульные тесты, чтобы гарантировать, что изменения в реализации не нарушают функциональность.
• запускаем ваши модульные тесты, используя внедрение зависимостей для передачи строки подключения тестовой базы данных из тестового кода в кодв тесте.

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

Вы можете контролировать, как часто вы хотите создавать базу данных модульных тестов: например, для тестового проекта, класса тестирования или метода тестирования, илисочетание путем создания базы данных в методе [AssemblyInitialize], [ClassInitialize] или [TestInitialize].

Это техника, которую мы используем с большим успехом. преимуществами являются:

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

Недостатки :

• модульные тесты зависятна внешней системе (СУБД).Вам нужно будет найти имя СУБД в коде настройки теста.Это можно сделать с помощью файла конфигурации или путем просмотра времени выполнения для работающей локальной СУБД.
• Проверка может быть замедлена сценариями установки базы данных.По нашему опыту, тесты все еще выполняются достаточно быстро, и есть много возможностей для оптимизации.Мы выполняем наш набор тестов из примерно 400 модульных тестов в течение примерно 1 минуты, который включает создание 5 отдельных баз данных в локальной установке SQLServer 2008.

Answer 2

Если вы можете создать «шов» между кодом бизнес-логики и уровнем доступа к данным, у вас все будет в порядке.Используйте интерфейсы для представления контракта, который ваш DAL предоставляет вашей бизнес-логике, а затем либо напишите свой собственный набор поддельных объектов, либо используйте инструмент для насмешек, такой как rhino-mocks.

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

Answer 3

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

Answer 4

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

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

Я хотел бы предложить вам написать специальные интеграционные тесты для хранимых процедур и вставить / удалить данные, как вы это делаете в настоящее время. Обратите внимание, что проще заключить тест в транзакцию, которую затем откатить. Вы также можете использовать функции «модульного тестирования» базы данных в Visual Studio для тестирования sprocs, если у вас есть такая возможность.

Для остальной части вашего кода смоделируйте ваш DAL в соответствии с предложением @Ben и протестируйте свою бизнес-логику как обычный модульный тест. Однако, учитывая сложность того, что ваш DAL является статическим классом, вам придется проделать некоторую работу, чтобы обернуть DAL и начать использовать класс-оболочку во всем приложении - немного похоже на то, как ASP.NET MVC работает с HttpContext. *

Answer 5

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

Answer 6

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