Я подумал, что поделюсь своим опытом использования MvcIntegrationTestFramework в проекте ASP.NET MVC 4. В частности, проект ASP.NET MVC 4 представлял собой веб-роль для облачной службы Windows Azure .
Хотя пример проекта из форка Джона Каннинга работал для меня (хотя я изменил сборку System.Web.Mvc с 3.0.0.0 на 4.0.0.0, что потребовало кучу редактирования в файле web.config, чтобы получить запускать и проходить тесты) я получал сообщение об ошибке при попытке запустить те же тесты для проекта веб-роли Azure ASP.NET MVC 4. Ошибка была:
System.Reflection.TargetInvocationException: Исключение было сгенерировано целью вызова.
Внутреннее исключение было:
System.InvalidOperationException: этот метод не может быть вызван во время предварительной инициализации приложения.
Мне стало интересно, чем проект Azure Web Role, основанный на ASP.NET MVC 4, отличается от обычного проекта ASP.NET MVC 4, и как такое различие может вызвать эту ошибку. Я немного поискал в интернете, но не встречал никого, кто пытался сделать то же самое, что и я. Вскоре мне удалось понять, что это было связано с Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener . Часть роли этого класса, по-видимому, состоит в том, чтобы гарантировать, что веб-роль выполняется в размещенной службе или в среде разработки (вы увидите сообщение об этом, если переключите проект запуска из проект облачной службы для проекта веб-роли внутри решения облачной службы, а затем попробуйте отладку).
Решение ? Я удалил соответствующий прослушиватель из файла Web.config моего проекта веб-роли:
<configuration>
...
<system.diagnostics>
<trace>
<listeners>
<!--Remove this next 'add' element-->
<add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=1.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
name="AzureDiagnostics"> <filter type="" /> </add>
</listeners>
</trace>
</system.diagnostics>
...
</configuration>
Затем я смог запустить интеграционные тесты в обычном режиме для моего проекта веб-роли. Однако я добавил слушателя в файлы преобразования Web.Debug.config и Web.Release.config, чтобы при обычном развертывании и отладке все было по-прежнему.
Возможно, это поможет кому-то, желающему использовать MvcIntegrationTestFramework для разработки на Azure.
EDIT
Я только что понял, что это решение может быть чем-то вроде «хака», потому что оно может не позволить вам провести интеграционное тестирование кода приложения, связанного с компонентами Azure (например, возможно, со специальными механизмами кэширования Azure). Тем не менее, я еще не сталкивался с какими-либо проблемами, связанными с этим, хотя я также еще не написал так много интеграционных тестов ...