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

Question

У нас есть набор сервисов в .NET 3.5 \ C # и WCF. Тесты NUnit требуют, чтобы службы работали и прослушивали запросы. Службам требуется обновленная база данных SQL, чтобы быть готовым к подключению.

В настоящее время раздел [SetUp] модульного теста выполняет две задачи:

• Выполните последние сценарии SQL для создания базы данных.
• Используйте System.Diagnostics.Process.Start для запуска режима командной строки служб.

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

Процесс запущен MSBuild.

Answer 1

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

Вы должны подумать об абстрагировании доступа к данным в интерфейс. Затем вы можете кодировать конкретную реализацию этого интерфейса для нормальной работы и использовать Dependency Injection для внедрения фиктивной реализации для ваших модульных тестов.

Answer 2

Много ли вы сделали с помощью инъекций зависимостей (DI)?

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

Вот сообщение, с которого можно начать Шаблон внедрения зависимости .
Прочитав это, посмотрите на его пост Unit-Testing Business Logic .

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

Вот ТАК сообщение о Mocking Frameworks , чтобы вы начали.

Я бы предложил разбить ваше тестирование на две отдельные части:

• Модульное тестирование (где вы будете использовать DI для макета внешних служб)
• Интеграционное тестирование (чем вы сейчас занимаетесь)

В конце тестов вы могли остановить свои сервисы, используя метод с атрибутом [TestFixtureTearDown].

Answer 3

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