Я пытаюсь создать представления в модульных тестах, но не могу обойти отсутствующий VirtualPathProvider. Большинство механизмов просмотра используют базовый класс VirtualPathProviderViewEngine, который получает поставщика из текущей среды HostingEnvironment.
protected VirtualPathProvider VirtualPathProvider {
get {
if (_vpp == null) {
_vpp = HostingEnvironment.VirtualPathProvider;
}
return _vpp;
}
set {
_vpp = value;
}
}
В модульных тестах нет HostingEnvironment, даже если я создаю его, нет текущего VirtualPathProvider.
Как я могу обойти эту проблему? Нужно ли мне создавать собственный FakeWebFormViewEngine?
Октябрь 2012 г. Даже со всеми замечаниями, которые сводятся к «вы неправильно тестируете!», Кто-то может быть заинтересован в реальном тестировании механизмов, которые полагаются на VirtualPathProvider. Так что просто любопытно: кто-нибудь добрался?





Я тоже пытался это сделать. К сожалению, проблема заключается не только в VirtualPathProvider (VPP). VPP используется для сопоставления представления или частичного представления с физическим путем для определения существования файла. К сожалению, ViewContext заканчивается виртуальным путем, а не физическим путем, поэтому при визуализации представления Builder использует свойства HostingEvnironment, которого не существует.
Если вы используете версию Visual Studio с тестированием, вы можете использовать модульный веб-тест. Это позволит вам использовать браузер для вызова URL-адреса, а затем проанализировать ответ для проверки значений.
Простите меня, если это звучит невежественно, но какова цель создания просмотров? Возможно, я чего-то упускаю, но основное внимание в модульных тестах уделяется «тестированию модуля». В правильно настроенном приложении ASP.NET MVC код, который необходимо протестировать, находится в контроллере и ниже. На самом деле, я бы сказал, если ее правильно разработать, то она ниже.
Тест представления - это приемочный тест пользователя. Я не вижу ничего плохого в том, чтобы автоматизировать это, в любом случае, но я не уверен, что это то, что нужно делать с помощью модульного теста.
Я что-то упускаю?
Я согласен, но есть некоторые сценарии, в которых, я думаю, полезен модульный тест. Существуют механизмы просмотра, которые позволяют "писать сценарии" внутри представлений (искры), я думаю, что несколько простых тестов для тестирования этих функций были бы отличными. Не поймите меня неправильно, я не хочу сравнивать сгенерированный HTML-код, это больше похоже на "видна ли форма входа?" вещи.
В VS Team System 2010 появятся функции приемочного тестирования, которые подходят для того, что вы пытаетесь сделать. Как упоминал Грегори, A Beamer Unit-тесты для MVC выполняются для контроллера. Вы также можете протестировать модель в зависимости от того, как вы реализуете свою модель.
Здесь много споров. Некоторые люди смотрят на модель как на бизнес-объекты, тогда как я смотрю на них как на представления модели, специфичной для представления. Больше модели просмотра. Поскольку в моей модели нет реальной функциональности, мне не нужно ее тестировать. Я тестирую свой DAL, уровень бизнес-логики вне MVC. MVC действительно является частью уровня представления. Это наслоение вашей презентации, а не ваше приложение. Вы все еще накладываете свое приложение на слои.
Что касается модульного тестирования, то вы тестируете именно контроллер. Вы можете протестировать свою модель, если есть методы, требующие тестирования. Что касается представлений, они проходят проверку пользователями или с помощью автоматизации, такой как Watin.
Вы можете попробовать Ивонна для интеграции (и, в некоторой степени, модульного) тестирования ваших представлений.
Вы когда-нибудь находили на это ответ? Я столкнулся с той же проблемой :-)