Методы модульного тестирования базы данных

Question

В настоящее время я работаю над проектом c #, который использует базу данных SQLite. Для проекта мне необходимо провести модульное тестирование, но мне сказали, что модульное тестирование не должно включать внешние файлы, такие как файлы базы данных для тестирования, и вместо этого тест должен эмулировать базу данных.

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

Answer 1

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

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

Таким образом, принцип, согласно которому модульные тесты должны избегать баз данных, в целом верен, но не является абсолютным правилом. Это просто (сильное) руководство, которое помогает структурировать сложные системы. При слишком строгом соблюдении этого правила очень сложно адекватно протестировать «граничные» компоненты, которые инкапсулируют внешние системы - места, в которых ошибки очень легко спрятать! Итак, вопрос, который действительно нужно задавать себе, когда модульный тест требует базу данных, заключается в следующем: является ли тестируемый компонент законным доступом к базе данных напрямую, или он должен вместо этого сотрудничать с другим, который несет эту ответственность?

То же самое относится и к использованию внешних файлов и других ресурсов в модульных тестах.

Answer 2

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

Во-вторых, Брайан сказал, что это хороший вариант, который я использовал раньше.

Answer 3

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

Лично мне нравится делать это на основе атрибутов.Указав сценарии Sql для выполнения каждого теста в качестве атрибута, например так:

[PreSqlExecute("SetupTestUserDetails.sql")]
[PostSqlExecute("CleanupTestUserDetails.sql")]
public void UpdateUserNameTest()
    {

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

К сожалению, это не стандартная функция с MS Runner, который поставляется с Visual Studio.Если вы используете Postsharp в качестве AOP-фреймворка, это легко сделать.Если нет, вы все равно можете получить те же функциональные возможности для стандартного MS Test Runner, используя функцию .Net, которая называется «Объекты, связанные с контекстом».Это позволяет вам вставлять пользовательский код в цепочку создания объектов для выполнения AOP-подобных вещей, пока ваши объекты наследуются от ContextBoundObject.

Я написал пост в блоге с более подробной информацией и небольшим полным примером кода.

http://www.chaitanyaonline.net/2011/09/25/improving-integration-tests-in-net-by-using-attributes-to-execute-sql-scripts/

Answer 4

С SQLite вы можете использовать базу данных в памяти . Вы можете подготовить базу данных, вставив данные, а затем запустить свои тесты на них.

Answer 5

Лучше всего использовать фальшивые рамки для имитации базы данных.Для C # существует Entity Framework .Даже использование sqlite является внешней зависимостью от вашего кода.

Answer 6

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

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

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

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