make - unit test c# visual studio 2017

¿Pones pruebas unitarias en el mismo proyecto u otro proyecto?

Question

¿Pone las pruebas unitarias en el mismo proyecto por conveniencia o las coloca en un ensamble por separado?

Si los coloca en un ensamble por separado como lo hacemos, terminaremos con una cantidad de proyectos adicionales en la solución. Es ideal para pruebas unitarias durante la codificación, pero ¿cómo se libera la aplicación sin todos estos ensamblajes adicionales?

Answer 1

Coloque las pruebas unitarias en el mismo proyecto que el código para lograr una mejor encapsulación.

Puedes probar fácilmente los métodos internos, lo que significa que no harás públicos los métodos que deberían haber sido internos.

También es muy agradable tener las pruebas de la unidad cerca del código que estás escribiendo. Cuando escribe un método, puede encontrar fácilmente las pruebas unitarias correspondientes porque está en el mismo proyecto. Cuando construyes un ensamblado que incluye unitTests, cualquier error en UnitTest te dará un compilereerror, por lo que debes mantener tu prueba unificada actualizada, solo para compilar. Tener una prueba unitaria en un proyecto separado, puede hacer que algunos desarrolladores olviden construir el proyecto de prueba unitario, y perder las pruebas rotas por un tiempo.

Y puede eliminar las pruebas unitarias del código de producción, utilizando etiquetas de compilación (IF #Debug).

Las pruebas de integración automática (realizadas en iNUnit) deben estar en un proyecto separado, ya que no pertenecen a ningún proyecto en particular.

Answer 2

En mi opinión, las pruebas unitarias deben colocarse en un ensamblaje separado del código de producción. Estos son algunos de los inconvenientes de colocar pruebas unitarias en el mismo ensamblaje o ensamblaje que el código de producción:

1. Las pruebas unitarias se envían con código de producción. Lo único que se envía con el código de producto es el código de producción.
2. Los ensamblajes serán innecesariamente hinchados por pruebas unitarias.
3. Las pruebas unitarias pueden afectar los procesos de compilación, como la creación automatizada o continua.

Realmente no sé de ningún profesional. Tener un proyecto extra (o 10) no es una estafa.

Editar: Más información sobre compilación y envío

Recomiendo además que cualquier proceso de compilación automatizado coloque la producción y las pruebas unitarias en diferentes ubicaciones. Idealmente, el proceso de compilación de pruebas unitarias solo se ejecuta si el código de producción se genera y copia los archivos del producto en el directorio de pruebas de la unidad. Hacerlo de esta manera da como resultado que los bits reales se separen para el envío, etc. Además, es bastante trivial ejecutar pruebas unitarias automatizadas en este momento en todas las pruebas en un directorio particular.

Para resumir, aquí está la idea general para una compilación diaria y pruebas y envío de bits y otros archivos:

1. La producción se ejecuta, colocando los archivos de producción en un directorio específico de "producción".
   1. Desarrolle proyectos de producción solamente.
   2. Copie los bits compilados y otros archivos en un directorio de "producción".
   3. Copie los bits y otros archivos en un directorio de candidatos de lanzamiento, también conocido como un directorio de lanzamiento de Navidad sería "Release20081225".
2. Si la compilación de producción tiene éxito, se ejecuta compilación de pruebas unitarias.
   1. Copie el código de producción al directorio "tests".
   2. Construya pruebas unitarias en el directorio "pruebas".
   3. Ejecutar pruebas unitarias
3. Enviar notificaciones de compilación y resultados de pruebas de unidades a los desarrolladores.
4. Cuando se acepta un candidato de lanzamiento (como Release20081225), envíe estos bits.

Answer 3

Estoy realmente inspirado por el marco de pruebas unitarias de la biblioteca Flood NN de Robert Lopez. Utiliza un proyecto diferente para cada clase probada de unidad, y tiene una solución que contiene todos estos proyectos, así como un proyecto principal que compila y ejecuta todas las pruebas.

Lo bueno es también el diseño del proyecto. Los archivos fuente están en una carpeta, pero luego la carpeta del proyecto VS está debajo. Esto le permite crear diferentes subcarpetas para diferentes compiladores. Todos los proyectos de VS se envían con el código, por lo que es muy fácil para cualquiera ejecutar cualquiera o todas las pruebas unitarias.

Answer 4

Fluctivo entre el mismo proyecto y diferentes proyectos.

Si está liberando una biblioteca, liberar el código de prueba con el código de producción es un problema, de lo contrario, generalmente no lo es (aunque hay una fuerte barrera psicológica antes de intentarlo).

Al realizar pruebas en el mismo proyecto, me resulta más fácil cambiar entre las pruebas y el código que prueban, y más fácil refactorizarlas / moverlas.

Answer 5

Las pruebas de mi unidad siempre van en un proyecto separado. De hecho, por cada proyecto que tengo en mi solución, hay un proyecto de prueba separado que lo acompaña. El código de prueba no es un código de aplicación y no debe mezclarse con él. Una ventaja de mantenerlos en proyectos separados, al menos con TestDriven.Net, es que puedo hacer clic derecho en un proyecto de prueba y ejecutar todas las pruebas en ese proyecto, probando una biblioteca completa del código de la aplicación con un solo clic.

Answer 6

Los puse en proyectos separados. El nombre de la asamblea refleja el de los espacios de nombres, como regla general para nosotros. Entonces, si hay un proyecto llamado Company.Product.Feature.sln, tiene una salida (nombre de conjunto) de Company.Product.Feature.dll. El proyecto de prueba es Company.Product.Feature.Tests.sln, que produce Company.Product.Feature.Tests.dll.

Lo mejor es mantenerlos en una única solución y controlar la salida a través del Administrador de configuración. Tenemos una configuración con nombre para cada una de las ramas principales (Desarrollo, Integración, Producción) en lugar de utilizar la depuración y publicación predeterminadas. Una vez que tenga configurada la configuración, puede incluirla o excluirla haciendo clic en la casilla de verificación "Generar" en Configuration Manager. (Para obtener Configuration Manager, haga clic con el botón derecho en la solución y vaya a Configuration Manager). Tenga en cuenta que, en ocasiones, creo que el CM en Visual Studio tiene errores. En un par de ocasiones, tuve que ir al proyecto o a los archivos de la solución para limpiar los objetivos que creó.

Además, si está utilizando Team Build (y estoy seguro de que otras herramientas de compilación .NET son las mismas), puede asociar la compilación con una configuración con nombre. Esto significa que si no construyes las pruebas de tu unidad para tu compilación de "Producción", por ejemplo, el proyecto de compilación también puede tener en cuenta esta configuración y no construirlas ya que fueron marcadas como tales.

Además, solíamos hacer XCopy se cae de la máquina de construcción. La secuencia de comandos simplemente omitirá copiar algo llamado * .Tests.Dll de desplegarse. Fue simple, pero funcionó.

Answer 7

No entiendo la frecuente objeción a la implementación de pruebas con código de producción. Dirigí un equipo en un pequeño microcap (creció de 14 a 130 personas). Contamos con media docena de aplicaciones Java y consideramos EXTREMADAMENTE valioso implementar pruebas en el campo para ejecutarlas en una máquina específica que mostraba un comportamiento inusual. Se producen problemas aleatorios en el campo y ser capaz de lanzar miles de pruebas unitarias en el misterio sin costo fue invaluable y a menudo se diagnosticaron problemas en minutos ... incluyendo problemas de instalación, problemas de RAM escamosa, problemas específicos de la máquina, problemas de red escamosa, etc., etc. Creo que es increíblemente valioso poner pruebas en el campo. Además, surgen problemas aleatorios en momentos aleatorios y es bueno tener las pruebas unitarias sentadas allí esperando a ser ejecutadas en cualquier momento. El espacio en el disco duro es barato. Al igual que tratamos de mantener juntos los datos y las funciones (diseño OO), creo que hay algo fundamentalmente valioso en mantener juntos el código y las pruebas (función + pruebas que validan las funciones).

Me gustaría poner mis pruebas en el mismo proyecto en C # /. NET / Visual Studio 2008, pero aún no he investigado esto lo suficiente para lograrlo.

Un gran beneficio de mantener a Foo.cs en el mismo proyecto que FooTest.cs es que los desarrolladores recuerdan constantemente cuando a una clase le falta una prueba de hermanos. Esto fomenta mejores prácticas de codificación basadas en pruebas ... los agujeros son más evidentes.

Answer 8

Proyecto separado, pero en la misma solución. (He trabajado en productos con soluciones separadas para códigos de prueba y producción; es horrible. Siempre cambias entre los dos).

Las razones de los proyectos separados son las que otros afirman. Tenga en cuenta que si está utilizando pruebas basadas en datos, puede terminar con una cantidad bastante grande de hinchazón si incluye las pruebas en el ensamblaje de producción.

Si necesita acceder a los miembros internos del código de producción, use InternalsVisibleTo .

Answer 9

Proyectos separados, aunque debato conmigo mismo si deberían compartir el mismo svn. Por el momento, les estoy dando repositorios svn separados, uno llamado

"MyProject" - para el proyecto en sí

y uno llamado

"MyProjectTests" - para las pruebas asociadas con MyProject.

Esto es bastante limpio y tiene la ventaja de que se compromete con el proyecto y se compromete con las pruebas. También significa que puede entregar el svn del proyecto si es necesario, sin tener que liberar sus pruebas. También significa que puede tener directorios de ramificación / troncal / etiqueta para sus pruebas y para su proyecto.

Pero cada vez me siento más inclinado a tener algo como lo siguiente, en un único repositorio de svn, para cada proyecto.

MyProject |/Trunk | |/Code | /Tests |/Tags | |/0.1 | | |/Code | | /Tests | /0.2 | |/Code | /Tests /Branches /MyFork |/Code /Test

Me interesaría saber qué piensan los demás de esta solución.

Answer 10

Si se utiliza el marco NUnit , existe un motivo adicional para colocar las pruebas en el mismo proyecto. Considere el siguiente ejemplo del código de producción mezclado con pruebas unitarias:

public static class Ext
{
[TestCase(1.1, Result = 1)]
[TestCase(0.9, Result = 1)]
public static int ToRoundedInt(this double d)
{
return (int) Math.Round(d);
}
}

Las pruebas unitarias aquí sirven como documentación y especificación para el código que se prueba. No sé cómo lograr este efecto de auto-documentación, con las pruebas ubicadas en un proyecto separado. El usuario de la función tendría que buscar las pruebas para ver esos casos de prueba, lo que es poco probable.

Actualización : sé que el uso del atributo TestCase no fue lo que los desarrolladores de NUnit intentaron, pero ¿por qué no?

Answer 11

Yo diría que los mantengan separados.

Además de las otras razones mencionadas, tener código y pruebas juntas sesga los números de cobertura de prueba. Cuando informa sobre la cobertura de prueba unitaria: la cobertura informada es más alta porque las pruebas están cubiertas cuando realiza pruebas unitarias. Cuando informa sobre la cobertura de prueba de integración, la cobertura informada es menor porque las pruebas de integración no ejecutan pruebas unitarias.