Тестирование постоянных методов доступа к данным

Question

Просто интересно, есть ли у кого-нибудь идеи о том, как проверить свои методы доступа к данным. Я обнаружил, что тестирование методов доступа к поисковым данным намного проще, потому что я могу просто смоделировать ExecuteReader и вернуть заполненный dataTable.CreateDataReader(). Делая это, я могу проверить, правильно ли заполняется мой объект, если возвращен набор результатов.

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

Есть идеи? Приветствия

Answer 1

Мы используем в памяти дБ (hsql) для наших модульных тестов. Настройка запускает транзакцию, а демонтаж откатывает ее обратно. Тогда вы всегда будете знать состояние БД в своих модульных тестах.

Answer 2

Для нашей среды O / R Mapper LLBLGen Pro мы используем специализированные базы данных для тестов и различные тестовые проекты для каждой группы функций. Таким образом, у нас есть специальная база данных для вставок / обновлений, например, специальная база данных для тестирования действий, связанных с наследованием, специальная база данных для больших наборов, специальная база данных для извлечения. Кроме того, мы разделили модульные тесты в разных проектах: ориентированные на выборку, ориентированные на провайдера linq, ориентированные на вставку / обновление / удаление, ориентированные на оперативную память и т. Д.

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

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

Answer 3

Насмешка - это путь. Используя что-то вроде Moq , вы можете предоставить фиктивное соединение (например, IDbConnection) вашему классу доступа к данным и проверить, правильно ли установлены параметры, созданные для команды, созданной соединением.

Некоторое время назад я написал сообщение в блоге (см. здесь ), в котором описан способ имитации последовательных вызовов IDbCommand.CreateParameter. После настройки макетированных параметров вы можете проверить, установлены ли их свойства Value и ParameterName.