Как делают меня персистентность модульного теста?

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

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

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

Каковы лучшие практики для того, чтобы сделать их?


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

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

46
задан Lukas Eder 14 August 2012 в 14:05
поделиться

9 ответов

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

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

18
ответ дан Mike Stone 26 November 2019 в 20:40
поделиться

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

DbUnit (Java)

DbUnit.NET

16
ответ дан Community 26 November 2019 в 20:40
поделиться

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

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

4
ответ дан Rytmis 26 November 2019 в 20:40
поделиться

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

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

С уважением,

Грабят G

3
ответ дан OJ. 26 November 2019 в 20:40
поделиться

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

2
ответ дан dlinsin 26 November 2019 в 20:40
поделиться

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

2
ответ дан N00b Pr0grammer 26 November 2019 в 20:40
поделиться

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

1
ответ дан David Sykes 26 November 2019 в 20:40
поделиться

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

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

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

        [SetUp]
        public void Setup()
        {

        }

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

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

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

1
ответ дан Dan 26 November 2019 в 20:40
поделиться

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

1
ответ дан Thomas Eyde 26 November 2019 в 20:40
поделиться
Другие вопросы по тегам:

Похожие вопросы: