¿Proyectos de prueba unitarios o múltiples unidades por solución?

Question

Normalmente tengo una asignación de 1: 1 entre mis ensamblajes de producto y mis conjuntos de prueba de unidad. Yo por lo general trato de mantener el número total de conjuntos baja, y una solución típica puede ser algo como ...

• Cliente (Contiene Vistas, controladores, etc.)
• Client.Tests
• Común (Contiene datos/contratos de servicios, etc Común Utilidades)
• Common.Tests
• servidor (contiene dominio, servicios, etc)
• Server.Tests
• Server.WebHos t

Últimamente en el trabajo, las personas han mencionado que tienen un solo proyecto de prueba de unidad frente a descomponerlos por el conjunto que están probando. Sé que en el día, esto hizo la vida más fácil si estuviera ejecutando NCover, etc., como parte de su compilación (ya no importa por supuesto).

¿Cuál es la lógica general detrás de los proyectos UnitTest individuales o múltiples? Además de reducir el número de proyectos en una solución, ¿hay alguna razón concreta para ir de un lado o del otro? Me da la impresión de que esta puede ser una de esas cosas de "preferencia", pero Google no ha aparecido demasiado.

Answer 1

Hay sin respuesta definitiva porque todo depende de lo que trabaje, así como el gusto personal. Sin embargo, definitivamente desea organizar las cosas de manera que pueda trabajar eficazmente.

Para mí esto significa, quiero encontrar las cosas rápidamente, quiero ver qué prueba qué, quiero ejecutar cosas más pequeñas para tener un mejor control en caso de que quiera crear un perfil o hacer otras cosas en las pruebas también. Esto suele ser bueno cuando depura pruebas fallidas. No quiero pasar más tiempo pensando en nada, debería hablar por sí mismo cómo se mapean las cosas y qué pertenece a qué.

Otra cosa muy importante para mí es que quiero aislar tanto como sea posible y tener límites claros. Desea proporcionar una manera fácil de refactorizar/mover partes de su gran proyecto en un proyecto independiente.

Personalmente, siempre organizo mis pruebas sobre cómo está estructurado mi software, lo que significa un mapeo uno a uno entre la clase y sus pruebas, la biblioteca y el ejecutable de prueba. Esto le proporciona una estructura de prueba agradable que refleja su estructura de software, que a su vez proporciona claridad para encontrar cosas. Además, proporciona una división natural en caso de que algo se mueva de forma independiente.

Esta es mi elección personal después de probar varias formas de hacer las cosas.

En mi opinión, agrupar cosas cuando hay demasiadas no es necesariamente algo bueno. Puede ser, pero creo que en el contexto de esta discusión es el argumento equivocado para un único proyecto de prueba. Demasiados proyectos de prueba con muchos archivos en el interior significan solo uno con muchos archivos de prueba. Creo que el verdadero problema es que la solución en la que estás trabajando es cada vez más grande. Tal vez hay otras cosas que puede hacer para evitar tener "un mundo". :)

Answer 2

Parte del razonamiento que diría es que te obliga a alistar solo el conjunto que estás probando. Entonces, las pruebas de su Unidad no se convierten accidentalmente en pruebas de integración o algo peor. Ayuda a asegurar la separación de las preocupaciones.

Answer 3

No estoy seguro de un estándar en particular, pero en mi opinión, dividirlos en proyectos de prueba separados parece ser una mejor práctica. Me parece que es muy similar a la programación orientada a objetos en un nivel de solución/proyecto. Supongamos que uno de sus proyectos necesita ser reutilizado en algún lugar y desea poder llevar a cabo sus pruebas con usted. Si están en un proyecto separado de las otras pruebas y son exclusivos de ese proyecto en particular, simplemente transfiere ese proyecto también. De lo contrario, tiene que ir a pescar a través del proyecto de prueba masiva.

Además, la separación de proyectos ayuda a mantener las cosas ordenadas al depurar. En lugar de tener que abrir un solo proyecto masivo e ir a buscar el archivo de prueba que necesita, es mucho más simple si tiene un proyecto de prueba correspondiente para los proyectos funcionales ... reduce drásticamente su búsqueda.

Una vez más, creo que esto es una cosa preferencia, nunca he oído un definitivo asentamiento de un modo u otro, pero no es mi granito de arena vale la pena ...

Answer 4

que en realidad podría llegar al extremo de diciendo que si consideras dividir tus pruebas en diferentes proyectos para probar un ensamblaje, entonces ese ensamblaje es demasiado grande. Por lo general, dividí mis proyectos en pequeños componentes reutilizables, con pequeñas pruebas de 1-1 asignadas. Esto podría conducir a un desbordamiento de DLL, y podría no siempre ser posible con ciertos proyectos (como un proyecto web, donde no está tan lógicamente limpio dividir los controladores en diferentes ensamblajes). Solo una idea.

Answer 5

Además de las otras (buenas) respuestas, considere que en equipos de proyecto más grandes los miembros del equipo individual pueden crear sus propias soluciones para incluir solo el subconjunto de proyectos en los que están trabajando.

Asumiendo una solución monolítica, con un proyecto de prueba que cubre todo en esa solución, se rompe en ese escenario.