Базы Данных Модульного Тестирования

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

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

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

DBunit

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

Обычным решением для внешних зависимостей в модульных тестах является использование фиктивных объектов - то есть библиотек, имитирующих поведение реальных объектов, с которыми вы проводите тестирование. Это не всегда просто, и иногда требуется некоторая изобретательность, но есть несколько хороших (бесплатных) макетов библиотек для .Net, если вы не хотите "roll your own". Две сразу приходят на ум:

Носорог издевается над тем, что имеет довольно хорошую репутацию.

NMock -это другое.

Кроме того, существует множество коммерческих библиотек макетов. Частью написания хороших модульных тестов является фактическое удаление кода для них - например, с помощью интерфейсов, где это имеет смысл, так что вы можете "mock" зависимый объект, имплицируя версию "fake" его интерфейса, которая тем не менее ведет себя предсказуемым образом, для целей тестирования.

В database mocks это означает "mocking" ваш собственный слой доступа DB с объектами, которые возвращают составленные объекты таблицы, строки или набора данных для обработки модульными тестами.

Там, где я работаю, мы обычно создаем свои собственные фиктивные библиотеки с нуля, но это не значит, что вы должны это делать.

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

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

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

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

Шаблоны Модульного Тестирования

Я объяснил технику, которую я использовал для этой самой ситуации здесь .

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

Единственная проблема, которую вы можете не найти "great", заключается в том, что я обычно делаю полный тест CRUD (не чистый с точки зрения модульного тестирования), но этот интеграционный тест позволяет вам увидеть ваш код отображения CRUD + в действии. Таким образом, если он сломается, вы будете знать, прежде чем запустить приложение (экономит мне тонну работы, когда я пытаюсь идти быстро)

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

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

    [TestFixture]
    public class TrannsactionScopeTests
    {
        private TransactionScope trans = null;

        [SetUp]
        public void SetUp()
        {
            trans = new TransactionScope(TransactionScopeOption.Required);
        }

        [TearDown]
        public void TearDown()
        {
            trans.Dispose();
        }

        [Test]
        public void TestServicedSameTransaction()
        {
            MySimpleClass c = new MySimpleClass();
            long id = c.InsertCategoryStandard("whatever");
            long id2 = c.InsertCategoryStandard("whatever");
            Console.WriteLine("Got id of " + id);
            Console.WriteLine("Got id of " + id2);
            Assert.AreNotEqual(id, id2);
        }
    }

Если вы используете LINQ - SQL в качестве ORM, то вы можете создать базу данных on-the-fly (при условии, что у вас есть достаточный доступ из учетной записи, используемой для модульного тестирования). Видите http://www.aaron-powell.com/blog.aspx?id=1125