Test unitaire du site Web ASP.net Code du projet stocké dans App_Code

Question

J'ai un projet de site Web ASP.net (.net 3.5). Actuellement, tous les fichiers non codés (y compris les éléments Linq2Sql, les contextes de données, la logique commerciale, les méthodes d'extension, etc.) sont situés dans le dossier App_Code.

Je souhaite introduire les tests unitaires (à l'aide de nunit) dans au moins certaines sections du projet pour aller de l'avant. Tout test unitaire que je ferais devrait avoir un accès complet à tout le code qui se trouve actuellement dans le dossier App_Code. J'ai fait quelques lectures initiales jusqu'à présent, et le consensus semble être le suivant :

• Cela ne sera pas possible compte tenu de ma configuration actuelle
• Les tests unitaires nécessitent de référencer des classes qui font partie d'une dll compilée, et un projet de site web, par définition, ne se compile qu'au moment de l'exécution.
• Pour ce faire, je dois soit convertir l'ensemble de mon projet en une application Web, soit déplacer l'ensemble du code que je souhaite tester (c'est-à-dire tout le contenu de App_Code) dans un projet de bibliothèque de classes et faire référence à ce projet de bibliothèque de classes dans le projet de site Web. L'une ou l'autre de ces solutions me permettra d'accéder aux classes dont j'ai besoin au format dll compilé, ce qui me permettra de les soumettre à des tests unitaires.

Est-ce exact ? Ou y a-t-il un autre moyen de faire des tests unitaires sans restructurer/refactoriser l'ensemble de mon projet ?

Answer 1

Mon atelier a finalement trouvé une réponse à ce problème pour notre projet MVC. Et je veux la partager car j'ai poursuivi beaucoup d'impasses ici sur StackOverflow en entendant beaucoup de gens dire que ce n'était pas possible. Nous procédons de la manière suivante :

• Ouvrir le dossier MVC "en tant que site web, à partir d'un iis local", ce qui permet à l'intellisense et au débogage de fonctionner correctement.
• Ajouter un projet de test unitaire qui se trouve dans notre répertoire de contrôle des sources
• Ajouter une étape de pré-construction au projet TEST, puisque nous ne pouvons pas en ajouter une à un projet ouvert en tant que site web. Imaginez que le site web est \FooSite a notre projet test est \FooSite.Tests. Le code de l'application compilée dans FooSite.Tests \FooSite_Precompiled\bin. *

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

• Ajoutez une référence au fichier FooSite_Precompiled/bin/App_Code.dll dans votre projet de test.
• C'est tout. Vous pouvez avoir le beurre et l'argent du beurre. Chaque fois que vous cliquez sur Build dans votre solution, vous appelez l'outil aspnet_compiler.ext sur votre site web csproj (qui existe toujours) qui est capable, contrairement à MSBuild, de compiler le code de l'application, et le Debug="true" vous permet d'entrer dans le code de l'application. dans le code app_code.dll lors du débogage de votre test unitaire. De plus, vous n'avez besoin de Build n'est nécessaire que lorsque vous exécutez des tests unitaires mis à jour. Lorsque vous regardez les effets de votre changement sur la page, il vous suffit de Changer le code/Enregistrer/Rafraîchir la page puisque le dossier app_code se compile dynamiquement compile dynamiquement lorsqu'il est appelé depuis votre serveur web.

Answer 2

Vos conclusions semblent correctes. Je voterais pour le déplacement de la fonctionnalité dans un ou plusieurs projets de bibliothèques de classes, car cela peut ouvrir la porte à la réutilisation de la même fonctionnalité dans d'autres projets également.

Answer 3

Nous avons ce problème dans mon entreprise (mon patron n'aime pas les DLL, il y a des bêtises à propos des versions...).

Nous disposons de deux moyens de contournement que nous utilisons fréquemment :

1) Obtenir l'outil CI pour effectuer les tests unitaires : Nous utilisons TeamCity qui a une intégration NUnit assez étroite, et notre solution se construit assez rapidement (et a assez peu de tests) pour que ce soit une option valable.

2) précompiler et tester manuellement les binaires résultants : Il est parfaitement possible d'exécuter le compilateur ASP.net / MSBuild à partir de la ligne de commande (comme si vous faisiez une compilation "Publier") et de simplement tester les binaires qui en résultent.

Toutefois, si vous avez la possibilité de séparer le code en binaires (bibliothèques de classes) ou d'utiliser simplement une application web, je vous suggère cette solution.

Answer 4

Si quelqu'un se retrouve à mettre en œuvre la solution de Brian, voici un fichier Website.targets que vous pouvez inclure dans la solution de test unitaire. Il ne (re)compile le site web que lorsque l'App_Code change. Il suffit d'ajouter quelque chose comme

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

à votre fichier .csproj, en personnalisant le fichier WebsiteName et WebsitePath et vous devriez être prêt à partir. Site web.cibles :

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

Answer 5

Et comme l'a indiqué l'OP, il est également possible de passer à un projet d'application Web, ce qui est également plus propre, vos pages peuvent rester dans le projet d'application Web, vous les aurez dans une seule DLL (testable). Toute la logique métier, etc. se trouve dans une ou plusieurs bibliothèques de classes séparées.