Управляемые данными модульные тесты

Question

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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