Mejores prácticas para configurar un proyecto de Visual Studio para pruebas nUnit

Question

¿Cómo configuran las personas sus proyectos para Visual Studio y cómo hace referencia a la aplicación comprobable?

Ahora mismo he agregado un proyecto separado creando un .dll a mi solución que contiene todos los casos de prueba y referencias nunit.framework, y también hace referencia al archivo .exe principal directamente desde la carpeta Debug/donde VS genera La salida.

Pero no tengo idea si es una buena idea, o cuáles son las mejores prácticas, ¿alguien quiere compartir sus prácticas?

Answer 1

Eso suena muy bien para mí: puede distribuir o implementar su aplicación sin el ensamblaje de prueba y NUnit, pero todavía puede probar todo. Práctica bastante estándar.

Answer 2

He utilizado una carpeta separada para todas mis pruebas cuando las uso dentro de un proyecto. Luego, puede eliminar la carpeta fácilmente al hacer una compilación real si lo desea.

También he hecho lo que usted dice con un proyecto separado. Creo que está bien.

Answer 3

Normalmente, tengo una solución que contiene una cantidad de proyectos sin pruebas de unidad en esa solución principal: esta es la solución que se genera en el modo de lanzamiento para una verdadera construcción.

Para un proyecto específico, tengo una solución separada que contiene el proyecto Quiero probar la unidad (y cualquier dependiente) y un proyecto MyProjectName.UnitTests que albergan todas las pruebas unitarias para ese proyecto. Estos proyectos de prueba unitaria se configuran luego en una máquina de integración continua para obtener compilación en modo de depuración y luego se ejecutan las pruebas.

Funciona bien para mí.

Answer 4

Suponiendo que el proyecto de prueba está en la misma solución que el proyecto o proyectos bajo prueba, una pequeña mejora podría ser agregar una referencia al proyecto bajo prueba en lugar del binario en la carpeta Debug.

Además de lo que se ha mencionado aquí, a menudo también utilizo el atributo de ensamblaje InternalsVisibleTo para hacer que las clases internas del ensamblaje que estoy probando sean visibles para el ensamblaje de prueba, es decir, también pueden probarse directamente.

Dependiendo del marco de aislamiento de su elección, es posible que también necesite hacer visibles las partes internas de su conjunto bajo prueba para que los componentes del marco de aislamiento puedan simular ciertos comportamientos internos.

Answer 5

No creo que haya nada de malo en la entrega de dlls con código que demuestre que incluso el dll en un entorno de producción todavía funciona dentro de los parámetros establecidos :). En caso de errores extraños, aún puede ejecutar las pruebas unitarias con el dll de lanzamiento y ver si algo se rompió de una manera extraña. Debido a esto y porque no me gusta tener el doble de proyectos en una solución, prefiero agregar una carpeta de Pruebas en cada proyecto donde va todo el código de prueba de la unidad. Simple y efectivo.

Saludos,

Sebastiaan