Тестирование модуля ASP.net Веб-сайт Код проекта, хранящийся в App_Code

Ответ 1

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

Ответ 2

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

• Откройте папку MVC "как веб-сайт, из локального iis", который правильно работает с intellisense и отладкой.
• Добавьте проект unit test, который находится в нашем директории с контролируемым источником
• Добавить шаг предварительной сборки к проекту 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 в тестовом проекте.
• Бум это. Вы можете получить свой торт и съесть его тоже. Каждый раз, когда вы нажимаете "Создать" в своем решении, вы вызываете инструмент aspnet_compiler.ext на вашем веб-сайте csproj (который все еще существует), который, в отличие от MSBuild, для компиляции app_code, а Debug = "true" позволяет вам шаг в код app_code.dll при отладке unit test. А ты только нужно создавать, когда вы запускаете обновленные модульные тесты. когда вы смотрите на эффекты ваших изменений на странице, вы просто Изменить код/​​Сохранить/Обновить страницу с момента динамического добавления папки app_code компилируется при вызове с вашего веб-сервера.

Ответ 3

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

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

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

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

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

Ответ 4

Если кто-то найдет решение Brian, здесь файл 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 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>

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

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

Примечание:

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

Ответ 8

Мне пришлось изменить решение Брайана Уайта, добавив атрибут 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