c# - test - pruebas unitarias interfaz
C#- Excepto pruebas unitarias de la versión de lanzamiento de su proyecto (13)
¿Cómo se suele separar la base de código y las pruebas de unidades asociadas ? Conozco personas que crean un proyecto separado para pruebas unitarias, que personalmente encuentro confuso y difícil de mantener. Por otro lado, si mezcla el código y sus pruebas en un solo proyecto, termina con los binarios relacionados con el marco de prueba de su unidad (ya sea NUnit, MbUnit o lo que sea) y sus propios binarios uno al lado del otro.
Esto está bien para la depuración, pero una vez que construyo una versión de lanzamiento , realmente no quiero que mi código haga referencia al marco de prueba de la unidad .
Una solución que encontré es adjuntar todas las pruebas de su unidad dentro de las directivas #if DEBUG - #endif: cuando ningún código hace referencia a un ensamblaje de prueba unitaria, el compilador es lo suficientemente astuto como para omitir la referencia en el código compilado.
¿Hay alguna otra opción (posiblemente más cómoda) para lograr un objetivo similar?
Como los otros señalan, un proyecto de prueba separado (para cada proyecto normal) es una buena manera de hacerlo. Por lo general, duplico los espacios de nombres y creo una clase de prueba para cada clase normal con la ''prueba'' adjunta al nombre. Esto se admite directamente en el IDE si tiene Visual Studio Team System que puede generar automáticamente clases y métodos de prueba en otro proyecto.
Una cosa para recordar si desea probar clases y métodos con el acceso "interno" es agregar la siguiente línea al archivo AssemblyInfo.cs para cada proyecto que se probará:
[assembly: InternalsVisibleTo("UnitTestProjectName")]
Definitivamente estoy de acuerdo con todos los demás en que debe separar las pruebas de su código de producción. Sin embargo, si insistes en no, deberías definir una constante de conciliación condicional llamada TEST, y ajustar todas las clases de prueba de tu unidad con un
#if TEST
#endif
primero para asegurarse de que el código de prueba no compila en un escenario de producción. Una vez hecho esto, debe poder excluir los dlls de prueba de su implementación de producción, o incluso mejor (pero con mayor mantenimiento), crear un NAnt o MSBuild para la producción que se compila sin las referencias a los dlls de prueba.
El .Net framework después de v2 tiene una función útil en la que puede marcar un ensamblaje con el atributo InternalsVisibleTo que permite que otro acceda al ensamblaje.
Una especie de función de túnel de ensamblaje.
Puse las pruebas en un proyecto separado pero en la misma solución. De acuerdo, en las grandes soluciones puede haber muchos proyectos, pero el explorador de soluciones es lo suficientemente bueno para separarlos y si le das a todo nombres razonables, realmente no creo que sea un problema.
Recomendaría un proyecto separado para pruebas unitarias (y aún más proyectos para pruebas de integración, pruebas funcionales, etc.). Intenté mezclar códigos y pruebas en el mismo proyecto y encontré que es mucho menos fácil de mantener que separarlos en proyectos separados.
El mantenimiento de espacios de nombres paralelos y el uso de una convención de nombres sensata para las pruebas (por ejemplo, MyClass y MyClassTest) lo ayudarán a mantener la base de código mantenible.
Siempre creo un proyecto Acme.Stuff.Test separado que se compila por separado.
El argumento inverso es: ¿Por qué quieres sacar las pruebas? ¿Por qué no entregar la prueba? Si entregas las pruebas junto con un corredor de prueba, tienes algún nivel de prueba de aceptación y autoevaluación entregado con el producto.
He escuchado este argumento algunas veces y lo he pensado, pero personalmente aún sigo realizando pruebas en un proyecto separado.
Siempre guardo mis pruebas unitarias en un proyecto separado para que se compile en su propio ensamblaje.
Siempre que sus pruebas estén en un proyecto separado, las pruebas pueden hacer referencia a la base de código, pero la base de código nunca tiene que hacer referencia a las pruebas. Tengo que preguntar, ¿qué es confuso acerca de mantener dos proyectos? Puede mantenerlos en la misma solución para la organización.
La parte complicada, por supuesto, es cuando el negocio tiene 55 proyectos en la solución y el 60% de ellos son pruebas. Cuente con suerte.
Otra alternativa más para usar las directivas de compilación dentro de un archivo o crear un proyecto separado es simplemente crear archivos .cs adicionales en su proyecto.
Con algo de magia en el archivo del proyecto en sí, puedes dictar eso:
- Las DLL de nunit.framework solo se referencian en una compilación de depuración y
- sus archivos de prueba solo se incluyen en compilaciones de depuración
Ejemplo de fragmento de .csproj:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
...
<Reference Include="nunit.framework" Condition=" ''$(Configuration)''==''Debug'' ">
<SpecificVersion>False</SpecificVersion>
<HintPath>../../debug/nunit.framework.dll</HintPath>
</Reference>
...
<Compile Include="Test/ClassTest.cs" Condition=" ''$(Configuration)''==''Debug'' " />
...
</Project>
Para cada proyecto hay un proyecto .Test correspondiente que contiene pruebas en él.
Por ejemplo, para el ensamblado llamado, digamos "Acme.BillingSystem.Utils", habría un ensamblaje de prueba llamado "Acme.BillingSystem.Utils.Test".
Excluirlo de la versión de envío de su producto al no enviar ese dll.
Una cosa que aún debe tenerse en cuenta es que las versiones de VisualStudio anteriores a 2005 no permitían referenciar los proyectos de ensamblado EXE desde otros proyectos. Entonces, si está trabajando en un proyecto heredado en VS.NET, sus opciones serían:
- Coloque las pruebas unitarias en el mismo proyecto y use la compilación condicional para excluirlas de las compilaciones de versiones.
- Mueva todo a los ensamblados dll para que su exe sea solo un punto de entrada.
- Evite el IDE pirateando el archivo del proyecto en un editor de texto.
De las tres compilaciones condicionales es la menos propensa a errores.
Si la etiqueta #if (DEBUG) permite una versión limpia de "versión", ¿por qué necesitaría un proyecto separado para las pruebas? El nunit LibarryA / B ejemplo (sí, sé que es un ejemplo) hace esto. Actualmente luchando con el escenario. Había estado usando un proyecto separado, pero esto posiblemente permite algunas mejoras en la productividad. Todavía hummin y hawin.
Definitivamente abogo por separar tus pruebas en un proyecto separado. Es la única forma de ir en mi opinión.
Sí, como dice Gary , también te obliga a probar el comportamiento a través de métodos públicos en lugar de jugar con las entrañas de tus clases