Как я сохраняю unit test?

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

Я знаю, что технически это будет тест интеграции (а не unit test), но я хочу найти лучшие стратегии для следующего:

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

Каковы наилучшие методы для этого?

Что касается тестирования SQL: я знаю, что это можно сделать, но если я использую O/R Mapper, например NHibernate, он прикрепляет некоторые именованные бородавки в псевдонимах, используемых для выходных запросов, и, поскольку это несколько непредсказуемо, я не уверен, что смогу проверить это.

Должен ли я просто отказаться от всего и просто доверять NHibernate? Я не уверен, что разумный.

Ответ 1

Посмотрите на блок БД. Это библиотека Java, но должен быть эквивалент С#. Он позволяет вам подготовить базу данных с набором данных, чтобы вы знали, что находится в базе данных, затем вы можете взаимодействовать с блоком DB, чтобы узнать, что находится в базе данных. Он может работать против многих систем баз данных, поэтому вы можете использовать свою фактическую настройку базы данных или использовать что-то еще, например, HSQL в Java (реализация базы данных Java с опцией в памяти).

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

Ответ 2

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

DbUnit (Java)

DbUnit.NET

Ответ 3

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

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

Ответ 4

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

Я надеюсь, что это вам поможет - за последние 6 месяцев он работал очень хорошо для 3 активных проектов.

Привет,

Rob G

Ответ 5

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

Ответ 6

Для NHibernate я определенно выступаю за то, чтобы просто издеваться над API-интерфейсом NHibernate для модульных тестов - доверять библиотеке, чтобы делать правильные вещи. Если вы хотите убедиться, что данные действительно поступают в БД, выполните тест интеграции.

Ответ 7

Для проектов на основе JDBC можно использовать инфраструктуру Acolyte: http://acolyte.eu.org. Он позволяет макетировать доступ к данным, который вы хотите тестировать, используя абстракцию JDBC, без необходимости управлять конкретной тестовой БД.

Ответ 8

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

Ответ 9

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

С помощью С#, использующего mbUnit, вы просто используете атрибуты SqlRestoreInfo и RollBack

    [TestFixture]
    [SqlRestoreInfo(<connectionsting>, <name>,<backupLocation>]
    public class Tests
    {

        [SetUp]
        public void Setup()
        {

        }

        [Test]
        [RollBack]
        public void TEST()
        {
           //test insert. 
        }
    }

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

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

Ответ 10

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