Подтвердить что ты не робот

Рекомендуемая структура для тестирования Javascript с помощью QUnit в ASP.NET

У меня есть стандартное решение ASP.NET MVC (версия 2 preview 2) с фактическими проектными и серверными модульными тестами в отдельных проектах.

Поскольку этот проект очень тяжелый на стороне клиента, я хочу также создать проект ClientTest, который использует QUnit для тестирования основного проекта.

Я думал о создании обычного проекта веб-форм ASP.NET с одним файлом HTML, который загружал бы различные скрипты в моем каталоге Scripts/и тестировал их с помощью QUnit. К сожалению, это создаст еще один сервер разработки ASP.NET. Я мог бы настроить порт работающего сервера проектов MVC перед запуском тестов, но должен быть лучший способ, который не просто бросает тестовый файл html в основной проект MVC.

Кто-нибудь знает, как лучше это сделать?

4b9b3361

ОТВЕТЫ

Ответ 1

Мне нравится ваша идея размещения тестов QUnit в отдельном проекте. Как использовать XCOPY для копирования сценариев в событии предварительной сборки?

Скажите, что ваш проект MVC MyProj.Web, и ваш тестовый проект QUnit MyProj.ClientTest (замените его именами проектов).

  • Создайте папку Scripts в своем проекте ClientTest.

  • В Project > MyProj.ClientTest Свойствa > События сборки добавьте следующую команду в командную строку события Pre-build:

    XCOPY "$ (SolutionDir) MyProj.Web\Scripts" "$ (ProjectDir) Скрипты" /S/Y

  • Затем в вашем HTML просто включите соответствующие файлы JavaScript из папки Scripts.

Примечание. Вам нужно будет перестроить проект ClientTest, чтобы обновить файлы JavaScript, если вы хотите повторить тесты. Отрегулируйте имена папок, пути и XCOPY параметры по мере необходимости.

Ответ 2

Возможно, вы могли бы выбрать методы из в этой статье, включая использование командной строки, использование NUnit с WatiN, а также скрипинг результатов теста для составление отчетов. Это решение не требует отдельного проекта WebForms для проведения тестов, поскольку все это обрабатывается WatiN.

Ответ 3

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

Если ваше требование состоит в том, что вы хотите интерактивно запускать ваши тесты непосредственно на реальной странице, не затрагивая внешний вид этой страницы, вы можете проверить FireUnit для Firebug. Вы также можете обернуть FireUnit вокруг QUnit, как описано в блог Джона Ресига.

Если вы обеспокоены включением тестовых материалов, включите соответствующие сценарии в свои тестовые/отладочные сборки и отключите их/отключите в своих производственных сборках.