C#: exclusión de pruebas unitarias de la versión de lanzamiento de su proyecto

Question

¿Cómo sueles actuar? separando su base de código y las pruebas unitarias asociadas?Conozco personas que crean un proyecto separado para pruebas unitarias, lo que personalmente encuentro confuso y difícil de mantener.Por otro lado, si mezclas código y sus pruebas en un solo proyecto, terminarás con binarios relacionados con tu marco de pruebas unitarias (ya sea NUnit, MbUnit o cualquier otro) y tus propios binarios uno al lado del otro.

Esto está bien para depurar, pero una vez que construyo un versión de lanzamiento, Realmente no quiero que mi código hacer referencia al marco de pruebas unitarias ya no.

Una solución que encontré es incluir todas las pruebas unitarias 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 inteligente como para omitir la referencia en el código compilado.

¿Existen otras opciones (posiblemente más cómodas) para lograr un objetivo similar?

Answer 1

Definitivamente recomiendo separar sus pruebas en un proyecto separado.Es el único camino a seguir en mi opinión.

si, como gary dice, 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.

Answer 2

Como señalan los demás, un proyecto de prueba independiente (para cada proyecto normal) es una buena forma de hacerlo.Por lo general, reflejo los espacios de nombres y creo una clase de prueba para cada clase normal con "prueba" agregado 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 que debe recordar si desea probar clases y métodos con el descriptor de acceso "interno" es agregar la siguiente línea al archivo AssemblyInfo.cs para cada proyecto que se va a probar:

[assembly: InternalsVisibleTo("UnitTestProjectName")]

Answer 3

El marco .Net posterior a v2 tiene una característica útil donde puede marcar un ensamblaje con el atributo InternalsVisibleTo que permite que otra persona acceda al ensamblaje.
Una especie de función de túnel de montaje.

Answer 4

Otra alternativa más al uso de directivas del compilador dentro de un archivo o la creación de un proyecto separado es simplemente crear archivos .cs adicionales en su proyecto.

Con algo de magia en el archivo del proyecto, puedes dictar eso:

1. A las DLL nunit.framework solo se hace referencia en una compilación de depuración, y
2. sus archivos de prueba solo se incluyen en compilaciones de depuración

Ejemplo de extracto 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>

Answer 5

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ódigo y pruebas en el mismo proyecto y lo encontré mucho menos fácil de mantener que separarlos en proyectos separados.

Mantener espacios de nombres paralelos y utilizar una convención de nomenclatura sensata para las pruebas (p. ej.MyClass y MyClassTest) le ayudarán a mantener la base de código mantenible.

Answer 6

Siempre que sus pruebas estén en un proyecto separado, las pruebas pueden hacer referencia al código base, pero el código base nunca tiene que hacer referencia a las pruebas.Tengo que preguntar, ¿qué tiene de confuso mantener dos proyectos?Puedes mantenerlos en la misma solución para organización.

Lo complicado, claro, es cuando el negocio tiene 55 proyectos en la solución y el 60% de ellos son pruebas.Considérate afortunado.

Answer 7

Puse las pruebas en un proyecto aparte pero en la misma solución.Por supuesto, 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.

Answer 8

Para cada proyecto hay un proyecto .Test correspondiente que contiene pruebas.

P.ej.para el ensamblado llamado, digamos "Acme.BillingSystem.Utils", habría un ensamblado de prueba llamado "Acme.BillingSystem.Utils.Test".

Exclúyalo de la versión de envío de su producto al no enviar ese dll.

Answer 9

Siempre mantengo mis pruebas unitarias en un proyecto separado para que se compilen en su propio ensamblado.

Answer 10

Una cosa que aún debe considerarse es que las versiones de VisualStudio anteriores a 2005 no permitían que se hiciera referencia a proyectos de ensamblaje EXE desde otros proyectos.Entonces, si está trabajando en un proyecto heredado en VS.NET, sus opciones serían:

• Coloque pruebas unitarias en el mismo proyecto y utilice la compilación condicional para excluirlas de las versiones de lanzamiento.
• Mueva todo a 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.

Answer 11

Definitivamente estoy de acuerdo con todos los demás en que debes separar las pruebas de tu código de producción.Sin embargo, si insiste en no hacerlo, debe definir una constante de compilación condicional llamada TEST y envolver todas sus clases de prueba unitaria con una

#if TEST
#endif

Primero, asegúrese de que el código de prueba no se compile en un escenario de producción.Una vez hecho esto, debería poder excluir los archivos DLL de prueba de su implementación de producción o, mejor aún (pero con mayor mantenimiento), crear un NAnt o MSBuild para producción que se compile sin las referencias a los archivos DLL de prueba.

Answer 12

Siempre creo un proyecto Acme.Stuff.Test separado que se compila por separado.

El argumento inverso es:¿Por qué quieres sacarte las pruebas?¿Por qué no realizar la prueba?Si entrega las pruebas junto con un corredor de pruebas, tendrá algún nivel de prueba de aceptación y autoprueba entregados con el producto.

Escuché este argumento varias veces y lo pensé, pero personalmente todavía mantengo las pruebas en un proyecto separado.

Answer 13

Si el #si(DEPURACIÓN) La etiqueta permite una versión limpia de "lanzamiento", ¿por qué necesitarías un proyecto separado para las pruebas?El ejemplo nunit LibarryA/B (sí, sé que es un ejemplo) hace esto.Actualmente luchando con el escenario.Había estado usando un proyecto separado, pero esto parece permitir posiblemente algunas mejoras de productividad.Todavía hummin y hawin.