Тесты, передаваемые модулем данных

Question

Какова наилучшая практика тестирования API, которая зависит от данных из базы данных? Какие проблемы я должен соблюдать в среде «Непрерывная интеграция», которая запускает Unit Tests в рамках процесса сборки? Я имею в виду, что вы разворачиваете свою базу данных как часть скриптов сборки (может быть, запускаете ваш установщик), или я должен идти для жестко заданных данных [использовать MSTest Data Driven Unit Tests with XML]?

Я понимаю, что могу издеваться над слоем данных для уровня бизнес-логики, но что, если у меня возникли проблемы с SQL-операциями в DAL? Мне нужно попасть в базу данных, верно?

Ну ... это поток вопросов:) ... Мысли?

Answer 1

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

И, конечно же, никогда не проверяйте свою живую базу данных! Но это само собой разумеется :)

Answer 2

Единственное, что я сделал, это создать статические методы, которые вернули тестовые данные известного состояния. Затем я использовал бы «поддельный» DAL, чтобы возвращать эти данные, как если бы я действительно вызывал базу данных. Что касается тестирования sql/хранимой процедуры, я протестировал ее с помощью SQL Management Studio. YMMV!

Answer 3

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

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

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

Answer 4

Как уже упоминалось, искусно имитируйте вызовы БД в модульных тестах, если вы не хотите бесконечно возиться со своими тестами и данными. Тестирование sql-операторов подразумевает более integration test. Запустите это отдельно от модульных тестов, они - два разных зверя.