Когда поблочное тестирование, необходимо использовать базу данных для тестирования операций CRUD?

Обязательно ли при модульном тестировании использовать базу данных при тестировании операций CRUD?

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

Если так, то я бы объявил, что "Unit" и скажем, что вам действительно нужна база данных, и в идеале такая, которая, по крайней мере, хорошо представляла бы вашу базу данных, чтобы вас не поймали с SQL, специфичным для поставщика.

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

Изменить : пропущены 2/3 вашего вопроса. Извините.

Может ли sql lite помочь с этим?

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

Вы должны каким-то образом создавать базу данных в памяти?

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

Как и на все сложные вопросы, ответ таков: Зависит от:)

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

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

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

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

Некоторое время назад я писал о , как это сделать на SQL Server . Самая важная вещь, о которой нужно помнить, - это избегать соблазна создать General Fixture с некоторыми «репрезентативными данными» и пытаться повторно использовать его во всех тестах. Вместо этого вы должны вводить данные как часть каждого теста и очищать их после.

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

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

Теперь, что касается вашего вопроса, я бы посмотрел DbUnit.NET . Я не знаю .NET-версию этого инструмента, но могу сказать вам, что Java-версия отлично подходит для тестов, взаимодействующих с базой данных. В двух словах, DbUnit позволяет вам перевести базу данных в известное состояние перед запуском теста и выполнить утверждение для содержимого таблиц. Действительно удобно. Кстати, я бы рекомендовал прочитать страницу Лучшие практики ,

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

Для модульного тестирования таких операций рассмотрите используя некоторый типизированный объект mock-database. Например, если у вас есть класс, который инкапсулирует ваше взаимодействие с базой данных, извлеките из него интерфейс и затем создайте наследующий класс, который использует простые объекты в памяти вместо фактического подключения к базе данных.

Я написал утилиту под названием DBSnapshot , чтобы помочь проверить интеграцию баз данных sqlserver.

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

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

Вышеупомянутое гарантирует, что вы можете запускать каждый тест изолированно. Моя утилита DBSnapshot упростит ваш код, если вы напишете его .net. Я думаю, что его проще использовать, чем DbUnit.NET.

Как упоминалось выше, ключевым моментом здесь является наличие вашей тестовой базы данных в известное состояние до запуска тестов. В одном из реальных примеров у меня есть несколько сценариев SQL, которые запускаются перед тестами, которые воссоздают известный набор тестовых данных. Отсюда я могу протестировать операции CRUD и убедиться, что новые строки вставлены / обновлены / удалены.