Proyectos de pruebas en solución

Question

En .NET, ¿debería colocar proyectos de prueba unitaria con el resto de la solución? ¿O debería haber una solución de prueba que albergue todos los proyectos de prueba?

Tenemos todos los proyectos de prueba con nuestra solución de código base ... parece un poco engorroso.

¿Qué sueles hacer?

Answer 1

En nuestro proyecto actual decidimos poner todas las pruebas unitarias en proyectos separados. El código de aplicación y las pruebas están en la misma solución, pero al menos podemos construir (y desplegar) una versión sin el código de prueba de la unidad.

La desventaja de esto -hasta ahora- ha sido que a veces sus pruebas unitarias no pueden llegar a ciertos miembros del código de la aplicación (protegidos e internos), pero eso generalmente nos lleva a descubrir que nuestro diseño podría mejorarse.

Y creo que debo señalar un hilo similar Aquí con más respuestas sobre el mismo tema o similar.

Answer 2

Siempre los he mantenido como parte de la solución; después de todo, son parte de la solución. Sin embargo, puede tener múltiples soluciones para diferentes enfoques para ver sus proyectos, por lo que una solución sin prueba puede ser lo que desea crear en algunos casos.

Answer 3

Nuestro código de prueba no se envía, pero son parte de la solución en su conjunto. Nuestro constructor separa los ensambles de prueba y los componentes principales. Desde la perspectiva de la administración de soluciones, parece que una solución con más de 140 proyectos es abrumadora.

Answer 4

Siempre usamos un proyecto separado dentro de la misma solución.

Esto significa que podemos estar seguros (usando referencias) de que el código de prueba unitaria también prueba nuestras referencias explícitas (en lugar de recoger implícitamente algo de visibilidad de algo porque está en el mismo ensamblaje, por ejemplo, "Interno")

Answer 5

Generalmente pongo pruebas unitarias en su propio proyecto y pruebas de integración en su propio proyecto dentro de la solución de la aplicación.

Donde trabajo estamos considerando poner pruebas web en una solución separada. Planeamos compartir la creación de pruebas web con el equipo de control de calidad y no queremos que estas pruebas se conviertan en una responsabilidad de compilación.

Answer 6

No uso .NET, pero cuando desarrollo casos de prueba de cualquier tipo, los mantengo aislados del resto del código para poder implementar la aplicación sin las pruebas. El usuario no necesita, ni siquiera quiere esas cosas.

Answer 7

Mira el diseño de tu proyecto. Si está cerca del diseño de MVC o una de sus alternativas, debería tener distintos niveles de diferentes ensamblajes. Realice un subensamblaje de prueba para cada nivel de su diseño.

Nuestro proyecto de prueba generalmente se ejecuta en lugar del proyecto que crea el EXE. Nuestro proyecto EXE es un shell delgado que pasa eventos e información a un ensamblado lleno de clases de controlador que tiene el código que la mayoría de las personas ponen en un proyecto EXE. Esto permite que el Proyecto de prueba pretenda ser el EXE para el 90% del proceso de prueba normal.

Todavía estamos trabajando en la mejor disposición para los casos de prueba reales. En este momento tenemos varios niveles principales de nuestra utilidad de marco, objetos de aplicación, marco de interfaz de usuario, comandos, controladores de interfaz de usuario y EXE. Tenemos un ensamblaje para cada nivel, excepto EXE (que se prueba manualmente). Cuando editamos un ensamblaje, cargamos el ensamblaje de prueba para ese nivel. Cuando necesitamos hacer algo que toque todos los niveles, tenemos que cargar todos los ensambles de prueba.

Durante nuestro proceso de compilación de un botón, ejecutamos el proyecto de prueba exe. (Tenemos una utilidad separada para esto).