Лучший способ протестировать приложение на основе данных ASP.Net

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

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

Просто посмотрите, есть ли лучшие способы / инструменты для тестирования приложения ASP.Net.

14.12.2008 19:57:14
3 ОТВЕТА
РЕШЕНИЕ

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

Прямо сейчас есть ASP.Net MVC; тем не менее, шаблон MVC использовался в ASP.Net задолго до того, как появилась эта структура, поэтому, если вы рассматриваете возможность улучшения существующего приложения веб-форм, убедитесь, что вы не в конечном итоге посмотрите на более свежую информацию о ASP.Net MVC как модель программирования в ASP.Net.

Теперь предположим, что у вас есть основная логика для обработки нажатия кнопки, изолированного от страницы, поэтому у вас есть класс, назовем его WidgetController. Контроллер виджета может иметь метод HandleClick (), который выполняет вашу бизнес-логику.

Далее давайте предположим, что ваша бизнес-логика требует доступа к данным. Вы можете снова использовать разделение проблем. Ваша бизнес-логика не должна заботиться о том, как получить доступ к БД, все, что ей нужно, - это данные, позволяющие другому классу получать данные. Популярным способом разделения данных является использование модели Depedancy Injection или Inversion of Control (DI, IoC соответственно). По сути, вы определяете интерфейс для доступа к данным, и ваш контроллер будет программировать для этого интерфейса. Затем вы во время выполнения предоставляете фактический класс своему контроллеру с помощью некоторого метода (Property, Constructor и т. Д.)

Это позволяет вам предоставлять реализации MOCK во время выполнения, которые разделяют вашу БД. Моты будут реализовывать ваш интерфейс, и вы можете просто обновить объекты, которые ваши тесты должны будут хранить в памяти.

0
14.12.2008 20:47:51

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

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

0
14.12.2008 21:04:09

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

То, что вы упоминаете относительно сценариев таблиц базы данных и данных, а затем запуска сценария установки перед всеми интеграционными тестами, является довольно разумным подходом.

Не знаю, насколько вы поклонник ORM, но с помощью NHibernate вы можете перестроить свои таблицы из сопоставлений. После восстановления базы данных у меня обычно просто есть скрипт, который физически создает объекты и сохраняет их через NHibernate. Я знаю, что это не лучший подход, но я обычно нахожу, что объем данных запуска, который мне нужен, не так уж велик, и вставка через NHibernate сама по себе является тестом :-).

Я никогда не использовал Fitnesse, как упомянуто "Mike Scott", но я слышал хорошие вещи, и это выглядит интересно. Он также рекомендуется в печально известной статье Билли Маккаферти, которая дает хорошее краткое введение в некоторые отличные общие рекомендации по разработке, такие как модульное тестирование, DDD, проектирование по контракту и т. Д.

1
14.12.2008 21:50:03