Модульное тестирование кода проекта веб-сайта ASP.net, хранящегося в App_Code

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

Мой магазин наконец-то нашел ответ на этот вопрос для нашего проекта MVC. И я хочу поделиться этим, поскольку я гнался за множеством тупиков здесь, в StackOverflow, слыша, как многие люди говорят, что это невозможно. Делаем это так:

• Откройте папку MVC «как веб-сайт, из локального iis», который обеспечивает правильную работу intellisense и отладки.
• Добавьте проект модульного теста, который находится в нашем каталоге с исходным кодом.
• Добавьте этап предварительной сборки в проект TEST, поскольку мы не можем добавить его в проект, открытый как веб-сайт. Представьте, что веб-сайт - это \ FooSite, а наш тестовый проект - это \ FooSite.Tests. Скомпилированный код приложения окажется в FooSite.Tests \ FooSite_Precompiled \ bin.
*

<Target Name="BeforeBuild">
     <AspNetCompiler VirtualPath="FooSite" TargetPath="$(ProjectDir)\FooSite_Precompiled" Force="true"
 Debug="true" />   </Target>

• Добавьте ссылку на FooSite_Precompiled / bin / App_Code.dll в свой тестовый проект.
• Бум, вот и все. Вы можете съесть свой торт и съесть его. Каждый раз, когда вы нажимаете Build в своем решении, вы вызываете инструмент aspnet_compiler.ext на своем веб-сайте csproj (который все еще существует), который может, в отличие от MSBuild, компилировать app_code, а Debug = "true" позволяет вам перейти в app_code. dll при отладке модульного теста. И вам нужно только построить, когда вы запускаете обновленные модульные тесты. Когда вы смотрите на эффекты вашего изменения на странице, вы просто меняете код / ​​сохраняете / обновляете страницу, поскольку папка app_code динамически компилируется при вызове с вашего веб-сервера.

У нас есть эта проблема в моей компании (моему начальнику не нравятся библиотеки DLL, какая-то чушь про управление версиями ...)

У нас есть два способа обойти это, которые мы часто используем:

1) Получите инструмент CI для выполнения модульного тестирования: мы используем TeamCity, который имеет довольно тесную интеграцию с NUnit, и наше решение создается достаточно быстро (и имеет достаточно тестов), чтобы это было допустимым вариантом.

2) Выполните предварительную компиляцию и модульное тестирование полученных двоичных файлов вручную: вполне возможно запустить компилятор ASP.net / MSBuild из командной строки (как если бы вы выполняли сборку «Опубликовать») и просто выполнить модульное тестирование полученных двоичных файлов.

Однако, если у вас есть возможность разделить код на двоичные файлы (библиотеки классов) или просто использовать веб-приложение, я бы предложил это как лучшую альтернативу.

Если кто-то обнаружит, что внедряет решение Брайана, вот файл Website.targets, который вы можете включить в решение для модульного тестирования. Он (повторно) компилирует веб-сайт только при изменении App_Code. Просто добавьте что-нибудь вроде

  <PropertyGroup>
    <WebsiteName>MyWebsite</WebsiteName>
    <WebsitePath>..</WebsitePath>
  </PropertyGroup>
  <Import Project="$(ProjectDir)\Website.targets" />
  <Target Name="BeforeBuild" DependsOnTargets="CompileWebsite">
  </Target>

в ваш .csproj, настроив WebsiteName и WebsitePath, и вы должны быть готовы к работе. Website.targets:

<?xml version="1.0" encoding="utf-8"?>
<!--
    Target that compiles Website's App_Code to be used for testing
  -->
<Project DefaultTargets="CompileWebsite" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <AppCodeFiles Include="$(WebsitePath)\$(WebsiteName)\App_Code\**\*.*" />
  </ItemGroup>
  <Target Name="CompileWebsite" Inputs="@(AppCodeFiles)" Outputs="$(ProjectDir)\PrecompiledWeb\bin\App_Code.dll">
    <AspNetCompiler VirtualPath="$(WebsiteName)" PhysicalPath="$(WebsitePath)\$(WebsiteName)" TargetPath="$(ProjectDir)\PrecompiledWeb" Force="true" Debug="true" />
  </Target>
  <Target Name="CleanWebsite">
    <RemoveDir Directories="$(WebsitePath)\$(WebsiteName)\PrecompiledWeb" />
  </Target>  
</Project>

Похоже, это возможно при использовании App_code, но я бы либо перенес эту логику в собственный проект библиотеки классов, либо изменил тип проекта на веб-приложение, как предлагают Фредрик и Колин.

Я всегда создаю свои собственные проекты ASP.NET как проекты веб-приложений, а не как сайты.

И, как указано в OP, также можно перейти в проект веб-приложения, который, я бы сказал, тоже чище, ваши страницы могут оставаться в проекте приложения wep, у вас они будут в 1 DLL (тестируемой). Вся ваша бизнес-логика и т. Д. Находится в отдельной библиотеке / библиотеках классов.

Классы модульного тестирования, хранящиеся в папке App_Code, можно выполнять без преобразования проекта в веб-приложение или перемещения классов в проект библиотеки классов.

Все, что необходимо, - это настроить действия сборки файлов кода на компиляцию. Это приведет к тому, что отладка и модульное тестирование вашего веб-сайта будут выводить файл .dll.

Теперь, когда вы ссылаетесь на проект своего веб-сайта из проекта модульного теста, классы в папке app_code будут видны.

ЗАМЕТКА:

Установка Build Action в Compile файлов .cs приведет к тому, что ваш веб-сайт будет генерировать файл .dll при отладке и модульном тестировании. Файл .dll вызовет проблемы при отладке веб-сайта, потому что теперь IIS найдет ваш код в двух местах, в корзине и в папке App_Code, и не будет знать, какое из них использовать. В настоящее время я просто удаляю файл .dll, когда хочу отладить.

Мне пришлось изменить решение Брайана Уайта, добавив атрибут PhysicalPath. Кроме того, я не использую Default Web Site, и мне пришлось изменить свойство VirtualPath на имя моего веб-сайта.

<Target Name="BeforeBuild">
    <AspNetCompiler VirtualPath="myIISsitename.com" PhysicalPath="$(SolutionDir)MySiteFolder" TargetPath="$(ProjectDir)\MySite_Precompiled" Force="true" Debug="true" />
</Target>

Полученная dll будет по адресу MySite_Precompiled\App_Code.dll