Как мне выполнить тестирование на устойчивость?

Question

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

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

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

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

---

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

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

Answer 1

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

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

Answer 2

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

DbUnit (Java)

DbUnit.NET

Answer 3

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

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

Answer 4

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

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

С уважением,

Роб Г

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

Технически юнит-тесты устойчивости - это не юнит-тесты, а интеграционные тесты.

В C # с использованием mbUnit вы просто используете атрибуты SqlRestoreInfo и RollBack

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

        [SetUp]
        public void Setup()
        {

        }

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

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

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

Answer 10

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