Testy jednostkowe ASP.net Kod projektu strony internetowej zapisany w kodzie aplikacji

Mój sklep w końcu opracował odpowiedź na to dla naszego projektu MVC. I chcę się tym podzielić, ponieważ ścigałem wiele ślepych zaułków tutaj na StackOverflow słysząc, że wiele osób mówi, że nie można tego zrobić. Robimy to tak:

• Otwórz folder MVC "jako stronę internetową, z lokalnego iis", który pobiera intellisense i debugowanie działa poprawnie
• Dodaj projekt testów jednostkowych, który mieszka w naszym katalogu kontrolowanym przez źródło
• Dodaj etap wstępnego budowania do projektu testowego, ponieważ nie możemy dodać go do projektu, który jest otwarty jako strona internetowa. Strona Imagine jest \FooSite i nasz projekt testowy to \FooSite.Testy. Skompilowany kod aplikacji zakończy się w Pióropuszu.Tests\FooSite_Precompiled\bin.
*

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

• Dodaj odniesienie do FooSite_Precompiled/bin / App_Code.dll w projekcie testowym.
• Bum, to jest to. Możesz zjeść swoje ciasto i je zjeść. Za każdym razem, gdy klikniesz Build in your solution, wywołujesz aspnet_compiler.ext narzędzie na swojej stronie csproj (która nadal istnieje), która jest w stanie, w przeciwieństwie MSBuild, aby skompilować app_code, a debug = "true" pozwala na krok w app_code.kod dll podczas debugowania testu jednostkowego. A Ty trzeba budować tylko wtedy, gdy uruchamiasz zaktualizowane testy jednostkowe. Kiedy patrzysz na efekty swojej zmiany na stronie, po prostu Zmień kod/Zapisz/odśwież stronę od folderu app_code dynamicznie kompiluje po wywołaniu z serwera www.

Mamy ten problem w mojej firmie (mój szef nie lubi bibliotek DLL, jakieś bzdury o wersjonowaniu...)

Mamy dwa sposoby, z których często korzystamy:

1) Pobierz narzędzie CI do testów jednostkowych: używamy TeamCity, który ma dość ścisłą integrację NUnit, a nasze rozwiązanie buduje się wystarczająco szybko (i ma mało testów), aby było to prawidłową opcją.

2) ręcznie wstępnie skompilować i przetestować wynikowe pliki binarne: jest to całkowicie możliwe, aby uruchomić ASP.net kompilator / MSBuild z linii poleceń (tak jakbyś robił kompilację' Publish') i po prostu testować wynikowe pliki binarne.

Jeśli jednak masz możliwość segregowania kodu na binaria (biblioteki klas) lub po prostu za pomocą aplikacji internetowej, sugerowałbym to jako lepszą alternatywę.

Jeśli ktoś znajdzie się w implementacji rozwiązania Briana, oto strona internetowa.plik targets możesz dołączyć do rozwiązania do testów jednostkowych. To (re)kompiluje stronę internetową tylko wtedy, gdy App_Code zmienia. Wystarczy dodać coś w stylu

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

Do twojego .csproj, dostosowując WebsiteName i WebsitePath i powinieneś być gotowy do pracy. Strona internetowa.cele:

<?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>

Wygląda na to, że jest to możliwe przy użyciu App_code , ale albo przeniosłbym tę logikę do własnego projektu biblioteki klas lub zmienił typ projektu na aplikację webową, jak sugerują Fredrik i Colin.

Zawsze tworzę swoje ASP.NET projekty jako projekty aplikacji internetowych, a nie Stron Internetowych.

I jak OP stwierdził, że możliwe jest również przejście do projektu aplikacji internetowej, który powiedziałbym, że jest czystszy, Twoje strony mogą pozostać w projekcie aplikacji WEP, będziesz je miał w 1 DLL (testowalny). Cała twoja logika biznesowa itp. przechodzi do oddzielnej biblioteki klas / bibliotek.

Możliwe jest testowanie jednostkowe klas przechowywanych w folderze App_Code bez konwersji projektu do aplikacji internetowej lub przenoszenia klas do projektu biblioteki klas.

Wszystko, co jest konieczne, to ustawienie akcji budowania plików kodu do kompilacji. Spowoduje to debugowanie i testowanie jednostkowe witryny do wyjścia .plik dll.

Teraz, gdy odwołujesz się do projektu witryny z projektu testu jednostkowego, klasy w folderze app_code będą widoczne.

Uwaga:

Ustawianie swojego .pliki cs ' Build Action to Compile spowoduje, że Twoja strona wygenerujeplik dll dotyczący debugowania i testowania jednostek. The .plik dll spowoduje problemy podczas debugowania witryny, ponieważ IIS będzie teraz znaleźć kod w dwóch miejscach, kosz i folder App_Code i nie będzie wiedział, który z nich użyć. Obecnie po prostu usunąć .plik dll, gdy chcę debugować.

Musiałem zmienić rozwiązanie Briana White ' a dodając atrybut PhysicalPath. Dodatkowo nie używam Default Web Site i musiałem zmienić właściwość VirtualPath na nazwę mojej strony internetowej.

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

Wynik dll będzie w MySite_Precompiled\App_Code.dll