Как мне провести интеграционное тестирование с моим кодом, написанным с использованием модели провайдера ASP.NET?

Question

Я довольно новичок в модульном тестировании. У меня есть сайт, построенный в 3-х уровневой архитектуре, UI -> BLL -> DAL. И я использовал модель провайдера asp.net, поэтому, внеся изменения в файл web.config, я могу переключиться на DAL dll для нацеливания на разные источники данных, чтобы завершить DAL, пишется с Entity Framework.

Теперь мой вопрос: как мне выполнить модульное тестирование моего BLL? Я использую NUnit.

Если запустить / отладить мой сайт, asp.net/IIS загружает все и получает правильную конфигурацию из web.config, так что все работает, потому что точка входа из IIS. Теперь, если я использую графический интерфейс NUnit для тестирования и скажу, что у меня есть тестовый проект «MySite.Test.dll», в котором есть контрольные примеры для моего BLL, как среда тестирования получает правильную конфигурацию для успешного выполнения всего теста. Для загрузки правильного провайдера необходима информация в web.config!

Теперь в моем DAL есть файл App.config, созданный EntityFramework, и в нем есть только строка подключения. Должен ли я поместить все связанные с провайдером конфигурации в этот app.config? Или я упускаю какую-то общую картину о том, как правильно это сделать?

Это должно быть обычным делом, я думаю, что люди должны делать постоянно. Может ли кто-нибудь дать некоторые подробности о том, как мне выполнить модульное тестирование моей библиотеки.

Спасибо, Ray.

---

Изменить: После прочтения первых 2 ответов, я думаю, что я должен исправить свое описание с интеграционным тестированием. По сути, вместо IIS в качестве точки входа используйте инструменты GUI, такие как NUnit, для запуска и тестирования моего кода, поэтому NUnit -> BLL -> DAL. Как люди на самом деле это настраивают?

Спасибо, Ray.

Answer 1

Вместо файла "web.config" в вашем проекте модульного тестирования вам потребуется файл "MySite.Test.dll.config", в котором вы сможете ввести правильную конфигурацию для тестирования. Обратите внимание, что при использовании этого метода вы можете использовать другого поставщика для подключения к базе данных в памяти, если хотите.

Answer 2

Похоже, что вы пытаетесь сделать - это интеграционное тестирование ... Модульное тестирование, по определению, тестирование Plain Old .Net Classes изолированно. Нет базы данных, нет конфигурации ... так что ... как мне кажется, для правильного модульного тестирования вам необходимо провести рефакторинг вашего BLL в классы логики уровня обслуживания и домена, которые вы будете тестировать отдельно. Например: сервисный уровень использует классы логики домена, а ваш модульный тест использует их. Итак, доменные классы не попадают в базу данных, и вам не нужны строки подключения и все.

Однако, если вы хотите провести правильное интеграционное тестирование с базой данных, вы можете сделать то же самое. Если это то, что вам нужно - Google, нетрудно получить некоторые строки конфигурации в nunit.config или что-то ... Я не знаю деталей.

Однако я чувствую, что вы хотите сделать это модульное тестирование, а не интеграционное тестирование.

Спросите себя, ЧТО ТО ЧТО ХОЧУ ИСПЫТАТЬ? Модульное тестирование не проверяет «все». Рефакторинг, инвертирование зависимостей и попытка проверить вашу бизнес-логику изолированно.

Answer 3

У вас есть несколько вариантов в зависимости от того, насколько вы хотите быть изолированным от DAL. Если вы хотите задействовать DAL в своих тестах, вы можете скопировать раздел строки подключения файла app.config в файл app.config в вашем проекте модульного тестирования. Однако, как говорит @badbadboy, это действительно интеграционное тестирование, а не юнит-тестирование.

Если вы хотите выполнить надлежащее модульное тестирование, вы, вероятно, захотите использовать внедрение зависимостей и интерфейсы, чтобы позволить вам макетировать DAL из вашего BLL. Я использую LINQ-to-SQL, поэтому создаю интерфейс и класс-оболочку для DataContext. Это позволяет мне создать фиктивную базу данных, которая будет использоваться для модульного тестирования, чтобы тестировать мои классы сущностей изолированно.

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

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