Модульные тесты на основе данных
Как лучше всего тестировать API, который зависит от данных из базы данных? Какие проблемы мне нужно учитывать в среде «непрерывной интеграции», в которой модульные тесты выполняются как часть процесса сборки? Я имею в виду, разворачиваете ли вы свою базу данных как часть сценариев сборки (может быть запущена ваша программа установки) или мне следует использовать жестко закодированные данные [использовать модульные тесты, управляемые данными MSTest с XML]?
Я понимаю, что могу имитировать уровень данных для уровня бизнес-логики, но что, если у меня возникли проблемы с операторами SQL в DAL? Мне нужно попасть в базу данных, верно?
Ну ... это поток вопросов :) ... Мысли?
Ответы 4
Насколько это возможно, вы должны имитировать код, чтобы полностью избежать попадания в базу данных, но мне кажется, что вы правы в том, что нужно где-то тестировать свой SQL. Если вы пишете тесты, которые попадают в базу данных, один из ключевых способов избежать головной боли - убедиться, что ваша установка переводит данные в известное состояние, а не полагаться на уже имеющиеся подходящие данные.
И, конечно же, никогда не проверяйте свою действующую базу данных! Но это само собой разумеется :)
@Kasper - Предполагается, что у вас уже настроена база данных [в идеале путем запуска сценариев SQL из сборки] ... Когда у вас слишком много тестовых инструментов, я считаю, что лучший способ сделать это - сначала настроить базу данных с исходными данными.
Я создал статические методы, возвращающие тестовые данные известного состояния. Затем я бы использовал «поддельный» DAL, чтобы вернуть эти данные, как если бы я действительно звонил в базу данных. Что касается тестирования sql / хранимой процедуры, я тестировал ее с помощью SQL Management Studio. YMMV!
Что делать, если SQL генерируется динамически - например, разные предложения WHERE и т. д.?
Рекомендуется автоматически стереть тестовую базу данных, а затем заполнить ее данными тестовой оснастки, которые, как предполагается, будут присутствовать для всех тестов, которым необходимо подключиться к базе данных. База данных должна быть сброшена перед каждым тестом для надлежащей изоляции - неудачный тест, который вводит неверные данные, может вызвать ложные сбои в следующих тестах, и он становится беспорядочным, если вам нужно запускать тесты в определенном порядке для получения согласованных результатов.
Вы можете очистить и заполнить базу данных инструментами (DBUnit, DBUnit.NET, другими) или просто создать свои собственные служебные классы, чтобы делать то же самое.
Как вы сказали, другие уровни должны быть в достаточной мере отделены от классов, которые фактически попадают в базу данных, поэтому потребность в любой базе данных, участвующей в тестировании, ограничивается тестами, запускающими небольшое подмножество вашей кодовой базы. Компоненты доступа к вашей базе данных могут быть имитированы / заглушены для всего, что от них зависит.
Как уже упоминалось, используйте имитацию для имитации вызовов БД в модульных тестах, если вы не хотите бесконечно возиться со своими тестами и данными. Тестирование операторов sql подразумевает больше интеграционный тест. Запустите это отдельно от модульных тестов, это 2 разных зверя.
Эндрю, я не уверен ... Вы говорите, что DAL не может / не должен проходить модульное тестирование, но тестируется во время интеграции?
Если вы скатили свой собственный DAL, вы должны полностью протестировать его. Я хочу сказать, что модульное тестирование будет намного чище, если использовать имитацию, а не реальные вызовы базы данных. Это может быть невозможно в вашем случае, но если вы можете издеваться, то делайте это.
Итак, вы просто удаляете все данные в методе SetUp и выполняете вручную адаптированный SQL в качестве первого шага в тестовых примерах тестирования базы данных, верно?