Tengo una solución con> 270 proyectos, contiene varias carpetas, etc. Imagine que cada proyecto tiene pruebas unitarias, ¿cuál cree que es la mejor manera de organizarlos? En caso de que cada proyecto tenga Pruebas unitarias cerca, o debería crear una carpeta especial para ellos, o incluso una solución diferente para las pruebas unitarias.Mejor práctica: Organizar pruebas unitarias
¿Cómo se organizan para soluciones/proyectos tan grandes?
Debe tener uno (o más) proyectos de prueba de unidad por proyecto de destino. Esta es la única forma en que puede mantenerse flexible y variar el conjunto de pruebas de cada unidad junto con el proyecto objetivo.
Si usted tiene un proyecto de prueba de unidad que cubre más de un proyecto de destino, esto crea un artificial estrecho acoplamiento entre estos dos proyectos, porque no va a ser capaz de compilar el proyecto de prueba de unidad sin la totalidad de sus proyectos de destino. Esto, una vez más, hace que sea realmente difícil probar un solo proyecto de forma aislada, que es de lo que se trata la prueba de la unidad.
Si necesita compartir el código de prueba entre varios objetivos de prueba, siempre puede crear una biblioteca compartida con una API de prueba reutilizable y generalizada, siempre que no haga referencia a ninguno de los proyectos de destino.
Dicho esto, tengo que estar de acuerdo con Jon Skeet en que una solución con 270 proyectos es un olor estructural que debe abordarse primero (a menos que sea una solución de "compilación completa" utilizada para compilaciones automáticas).
Una única solución con 270 proyectos parece ser un problema para empezar. ¿Cuánto tiempo lleva abrir VS? :) (En serio, ¿puede combinar algunos proyectos o dividir la solución?)
Normalmente mantengo las pruebas unitarias en su propio proyecto, pero en la misma solución. Dentro del proyecto, refleje la estructura de carpeta/espacio de nombres del proyecto de producción. Eche un vistazo a cómo se organiza Noda Time para un ejemplo. He estado en compañías donde las mantuvieron en una solución separada, pero eso fue realmente doloroso. (Tenían una buena razón: las pruebas estaban en VS2005 y el código de producción fue 2003.)
A veces he establecido que el espacio de nombres predeterminado del proyecto de prueba sea el mismo que el proyecto de producción, eso es más importante en Java que en .NET (ya que le permite obtener acceso a los miembros de acceso de paquete) pero aún puede ser útil, ya que significa que la clase que va a probar no necesita ser importada.
Después de cambiar a Gallio desde el marco de prueba de Visual Studio incorporado, comencé a poner mis pruebas en una carpeta de prueba dentro del mismo proyecto. Para pequeñas clases de ayuda, incluso podría definir una prueba unitaria allí en la misma carpeta. Siempre y cuando los espacios de nombres sean relativamente pequeños (no me gusta tener carpetas de espacio de nombres extendidas), esto no agrega demasiado desorden para mí. De todos modos, más adelante, cuando esas clases han existido por un tiempo y son estables, puedes mover esas pruebas unitarias a una carpeta separada.
Entonces, cuando envía sus binarios de producción, ¿todavía tienen las clases de prueba? ¿Envías también los ensambles del marco de prueba, que presumiblemente tu proyecto tiene referencias? ¿Qué hay de los datos de prueba? –
Nunca había pensado demasiado porque trabajo en aplicaciones internas. Pero sí, supongo que el código de prueba sería enviado. Tendré que considerar esto en el futuro. – tster
1 unidad de proyecto de prueba es el camino a seguir. Intentamos reflejar nuestros proyectos y crear un proyecto de prueba para cada uno: terminó con pruebas rotas. –
No me gusta tenerlos en un proyecto separado porque hace que sea más difícil probar clases internas y métodos. – tster
@Arnis: ¿Por qué? Nunca he encontrado ningún problema con un proyecto de prueba por proyecto de producción. ¿Qué problemas te toparon? –