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

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

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

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

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


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

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

5.08.2008 09:43:01
10 ОТВЕТОВ
РЕШЕНИЕ

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

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

18
11.08.2008 09:40:44

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

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

4
5.08.2008 09:47:41

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

1
5.08.2008 10:19:08

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

2
5.08.2008 10:29:42
Я согласен, хотя я никогда не был пуристом TDD, я определенно вижу много преимуществ TDD, но, игнорируя реальность и не проверяя ваши записи, входящие и выходящие из вашей базы данных, вы не представляете, что на самом деле собирается делать ваше приложение. в дикой природе. Так много раз, прежде чем я получил назначенную мне «ошибку», мой код не работал, и я запустил свои модульные тесты и обнаружил, что другой разработчик растоптал весь мой sproc (злые злые sprocs) и никогда не хотел запускаться мои юнит-тесты, чтобы увидеть, что они сломали всю систему.
Chris Marisic 19.11.2009 14:50:55

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

2
10.05.2018 16:49:36

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

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

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

        [SetUp]
        public void Setup()
        {

        }

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

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

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

1
5.08.2008 11:39:20

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

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

С Уважением,

Роб Г

3
17.01.2012 11:29:04

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

DbUnit (Java)

DbUnit.NET

16
23.05.2017 12:17:44

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

1
27.08.2008 21:17:21

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

2
28.11.2018 21:20:46