My<cod/>.net
Как выполнить модульный тест на постоянство?
Как новичок в практике разработки на основе тестов, я часто оказываюсь в затруднительном положении, когда речь заходит о том, как сохранить модульный тест в базе данных.
Я знаю, что технически это был бы интеграционный тест (а не юнит-тест), но я хочу выяснить лучшие стратегии для следующего:
- Тестовые запросы.
- Тестовые вставки. Как я узнаю, что вставка, которая пошла не так, если она не работает? Я могу проверить его, вставив и затем запросив, но как я могу знать, что запрос не был ошибочным?
- Тестирование обновлений и удалений -- то же самое, что тестирование вставок
Каковы наилучшие методы для этого?
Что касается тестирования SQL: я знаю, что это можно сделать, но если я использую o/R Mapper, как NHibernate, он прикрепляет некоторые бородавки именования в псевдонимах, используемых для выходных запросов, и поскольку это несколько непредсказуемо, я не уверен, что смогу это проверить.
Должен ли я просто бросить все и просто довериться NHibernate? Я не уверен, что это разумно.
Посмотрите в блок DB. Это библиотека Java, но должен быть и эквивалент C#. Он позволяет подготовить базу данных с набором данных, так что вы знаете, что находится в базе данных, а затем вы можете взаимодействовать с блоком БД, чтобы увидеть, что находится в базе данных. Он может работать со многими системами баз данных, поэтому вы можете использовать свою фактическую настройку базы данных или использовать что-то другое, например HSQL в Java (реализация базы данных Java с опцией в памяти).
Если вы хотите проверить, что ваш код правильно использует базу данных (что вы, скорее всего, должны делать), то это способ изолировать каждый тест и убедиться, что база данных подготовлена к ожидаемым данным.
Как сказал Майк Стоун, DbUnit отлично подходит для приведения базы данных в известное состояние перед запуском тестов. После завершения тестов DbUnit может вернуть базу данных в то состояние, в котором она находилась до запуска тестов.
Вы выполняете модульное тестирование, издеваясь над подключением к базе данных. Таким образом, можно построить сценарии, в которых определенные запросы в потоке вызова метода завершаются успешно или завершаются неудачно. Я обычно строю свои фиктивные ожидания так, чтобы фактический текст запроса игнорировался, потому что я действительно хочу проверить отказоустойчивость метода и то, как он сам себя обрабатывает-специфика SQL не имеет отношения к этой цели.
Очевидно, это означает, что ваш тест на самом деле не будет проверять , что метод работает, потому что SQL может быть неправильным. Именно здесь начинаются интеграционные тесты. Поэтому я ожидаю, что у кого-то другого будет более подробный ответ, поскольку я сам только начинаю разбираться с ними.
Я написал здесь сообщение, касающееся модульного тестирования слоя данных , который охватывает именно эту проблему. Приношу извинения за (позорную) пробку, но статья слишком длинная, чтобы размещать ее здесь.
Я надеюсь, что это поможет вам - это очень хорошо работало для меня в течение последних 6 месяцев на 3 активных проектах.
С уважением,
Роб Джи
Проблема, с которой я столкнулся при модульном тестировании персистентности, особенно без ORM и таким образом издеваясь над вашей базой данных (соединением), заключается в том, что вы действительно не знаете, успешны ли ваши запросы. Вполне возможно, что ваши запросы специально разработаны для определенной версии базы данных и успешно выполняются только с этой версией. Вы никогда не узнаете этого, если будете издеваться над своей базой данных. Поэтому, на мой взгляд, упорство юнит-тестирования имеет лишь ограниченное применение. Вы всегда должны добавлять тесты, работающие против целевой базы данных.
Для проектов, основанных JDBC, мой помошник основы могут быть использованы: http://acolyte.eu.org . Это позволяет моделировать доступ к данным, которые вы хотите тестировать, извлекая выгоду из абстракции JDBC, без необходимости управлять конкретным тестом DB.
Технически юнит-тесты стойкости - это не юнит-тесты, а интеграционные тесты.
При использовании 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.
Что касается проверки того, был ли ваш запрос успешным, вам обычно нужно следовать за ним со вторым запросом, чтобы увидеть, была ли база данных изменена, как вы ожидаете.