initialize - Unit Testing ASP.net Web Site Código de proyecto almacenado en App_Code

xunit net testing framework (8)

Tengo un proyecto de sitio web ASP.net (.net 3.5). Actualmente, todos los archivos de código que no son de código subyacente (incluidos los elementos de Linq2Sql, contextos de datos, lógica comercial, métodos de extensión, etc.) se encuentran en la carpeta App_Code.

Estoy interesado en presentar Unit Testing (usando nunit) en al menos algunas secciones del proyecto en progreso. Cualquier prueba de unidad que yo haría necesitaría tener acceso completo a todo el código que se encuentra actualmente en la carpeta App_Code. He hecho algunas lecturas iniciales hasta el momento, y el consenso parece ser:

Esto no será posible dada mi configuración actual
Las pruebas unitarias requieren referencias a las clases que forman parte de un dll compilado, y un proyecto del sitio web, por definición, solo se compila en tiempo de ejecución.
Para proceder, tendré que convertir mi proyecto completo a una Aplicación Web, o mover todo el código que me gustaría probar (es decir, todo el contenido de App_Code) a un proyecto de biblioteca de clase y hacer referencia a la biblioteca de la clase proyecto en el proyecto del sitio web. Cualquiera de estos proporcionará acceso a las clases que necesito en formato dll compilado, lo que me permitirá probarlos en una unidad.

¿Es esto correcto? ¿O hay otra forma en que puedo probar la unidad sin reestructurar / refactorizar todo el proyecto?

Es posible probar las clases almacenadas en la carpeta App_Code sin convertir su proyecto a una aplicación web o mover sus clases a un proyecto de biblioteca de clases.

Todo lo que se necesita es establecer las acciones de compilación de los archivos de código para compilar. Esto causará que Debugging y Unit Testing tu sitio web muestren un archivo .dll.

Ahora cuando haga referencia al proyecto de su sitio web desde el proyecto de prueba de unidad, las clases en la carpeta app_code estarán visibles.

NOTA:

Establecer la Build Action de Compile archivos .cs hará que su sitio web genere un archivo .dll en la depuración y pruebas unitarias. El archivo .dll causará problemas cuando depure su sitio web porque IIS ahora encontrará su código en dos lugares, el contenedor y la carpeta App_Code y no sabrá cuál usar. Actualmente solo elimino el archivo .dll cuando quiero depurar.

Mi tienda finalmente ha resuelto una respuesta para esto para nuestro proyecto MVC. Y quiero compartirlo ya que perseguí un montón de callejones sin salida aquí en al escuchar que mucha gente dice que no se pudo hacer. Lo hacemos así:

Abra la carpeta MVC "como un sitio web, desde iis locales", que funciona inteligentemente y depurando funcionando correctamente
Agregue un proyecto de prueba de unidad que viva en nuestro directorio controlado de fuente
Agregue un paso previo a la construcción al proyecto TEST, ya que no podemos agregar uno a un proyecto que esté abierto como sitio web. Imagine el sitio web es / FooSite y nuestro proyecto de prueba es / FooSite.Test. El código de la aplicación compilada terminará en FooSite.Tests / FooSite_Precompiled / bin.
*

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

Agregue una referencia a FooSite_Precompiled / bin / App_Code.dll en su proyecto de prueba.
Boom eso es todo. Puedes tener tu pastel y comértelo también. Cada vez que hace clic en Construir en su solución, llama a la herramienta aspnet_compiler.ext en su sitio web csproj (que todavía existe) que, a diferencia de MSBuild, puede compilar app_code, y Debug = "true" le permite ingresar al app_code. código dll al depurar su prueba de unidad. Y solo necesita Build cuando ejecuta pruebas de unidades actualizadas. Cuando mira los efectos de su cambio en la página, simplemente cambia la página Código / Guardar / Actualizar ya que la carpeta app_code se compila dinámicamente cuando se la llama desde su servidor web.

Parece que esto es posible mientras sigo usando App_code , pero movería esta lógica a su propio proyecto de biblioteca de clase o cambiaría el tipo de proyecto a Aplicación web, como sugieren Fredrik y Colin.

Siempre creo mis propios proyectos ASP.NET como proyectos de aplicaciones web, no sitios web.

Si alguien se encuentra implementando la solución de Brian, aquí hay un archivo Website.targets que puede incluir en la solución de prueba de la unidad. Solo (re) compila el sitio web cuando App_Code cambia. Solo agrega algo como

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

a su .csproj, personalizando WebsiteName y WebsitePath y debería estar listo para funcionar. Website.targets:

<?xml version="1.0" encoding="utf-8"?>  <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>

Tenemos este problema en mi compañía (a mi jefe no le gustan los archivos DLL, algo de basura sobre el control de versiones ...)

Tenemos dos formas de usarlo con frecuencia:

1) Obtenga la herramienta CI para realizar la prueba unitaria: utilizamos TeamCity, que tiene una integración NUnit bastante estrecha, y nuestra solución se desarrolla lo suficientemente rápido (y tiene pocas pruebas suficientes) para que esta sea una opción válida.

2) Precompila y prueba manualmente los binarios resultantes: es perfectamente posible ejecutar el compilador ASP.net / MSBuild desde la línea de comando (como si estuvieras haciendo una compilación ''Publicar'') y simplemente probar los binarios resultantes.

Sin embargo, si tiene la opción de segregar el código en binarios (bibliotecas de clases) o simplemente usar una aplicación web, sugeriría que es una mejor alternativa.

Tus conclusiones parecen correctas. Yo votaría por trasladar la funcionalidad a uno o varios proyectos de biblioteca de clases, ya que eso podría abrir la puerta para reutilizar la misma funcionalidad en otros proyectos también.

Tuve que cambiar la solución de Brian White añadiendo el atributo PhysicalPath . Además, no estoy usando el Default Web Site y tuve que cambiar la propiedad VirtualPath al nombre de mi sitio web.

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

El dll resultante estará en MySite_Precompiled/App_Code.dll

Y como OP dijo que también es posible pasar a un proyecto de aplicación web, lo cual diría que es más limpio, sus páginas pueden permanecer en el proyecto de la aplicación wep, las tendrá en 1 DLL (comprobable). Toda su lógica de negocios, etc. va en una biblioteca de clases / bibliotecas separadas.