TDD con una gran solución de C# prácticamente imposible debido a la velocidad de compilación lenta

Question

Estoy trabajando en una solución grande con actualmente 60 conjuntos. Hay muchos ensambles que definen partes comunes para la solución, y luego algunos conjuntos de puntos de entrada al sistema.

TDD es prácticamente imposible en este momento, ya que un cambio de línea única en la capa de dominio más baja obliga a reconstruir casi toda la solución, ya que el ensamblaje de prueba hace referencia a varias capas de la solución.

¿Cuál es la mejor práctica, reducir el tiempo de construcción de sus actuales 75 segundos a un valor más aceptable 5 segundos más o menos? Esto hará que TDD sea factible nuevamente.

Al realizar pruebas unitarias, algunas clases requieren simulaciones definidas por interfaces de otros ensamblajes, y como tales tienen que ser referenciadas en el ensamblaje de prueba. Por lo tanto, no siempre es posible tener una única referencia a los otros ensambles, excepto en el nivel más bajo de la solución.

Answer 1

En mi humilde opinión el problema se encuentra aquí: "como el conjunto de prueba hace referencia a varias capas de la solución".
Debe tener un conjunto de prueba por conjunto que desee probar.
Cuando aún hace referencia a muchos ensambles en cada uno de sus ensamblajes de prueba, tiene un problema diferente: está creando pruebas de integración. Eso no es lo que quieres hacer en TDD.

Además de la actualización de su pregunta:
Normalmente, definiría las interfaces en otro conjunto que no sea la implementación. Por lo tanto, un cambio en la implementación de una clase de nivel bajo no debería afectar las clases de nivel superior que usan esas interfaces ...

Answer 2

Divide toda la solución en soluciones más pequeñas basadas en capas (o incluso más específicas) y deja que cada tener un conjunto específico de pruebas unitarias No puede hablar en serio con esta pregunta 60 proyectos en una sola solución ¿por qué alguien querría trabajar con ella? ¿Es una tarea común para usted hacer cambios en 10 de ellos en una hora?

Con TDD y grandes proyectos, normalmente las pruebas de ejecución son lentas, es el problema, no el tiempo de compilación. Deje que todo el proceso de compilación sea manejado por una máquina de compilación especial y realice la ejecución de prueba de toda la unidad de construcción completa & solo al registrarse.

Esto hará que su desarrollo vuelva al TDD normal.

Answer 3

Otras personas han dicho que refactorizar etc, grande si usted es capaz de ...

Hay algunas otras cosas que son más fáciles de hacer:

• Combine pequeños proyectos en grande proyectos, ya que hay una gran sobrecarga por proyecto en la construcción de una solución. (Uso nDepend si es necesario para controlar llamando a través de las capas, las reglas se puede definir en "Code Query Language" y después se comprueba como parte de su construcción)

• Hacer todos los proyectos se acumulan en el directorio alguna salida a continuación, ajuste “copia local” a falso en todas las referencias del proyecto; esto puede conducir a una gran velocidad debido a IO reducido.

• Apague el comprobador de virus para ver si hace mucha diferencia; en caso afirmativo, encuentre un faster virus checker, o excluya las carpetas "activas" de la herramienta antivirus

• Utilice el monitor forzosa y la herramienta interna sys para ver cómo sus compilaciones tardan tanto.

• Considere un disco RAM para poner su directorio de salida.

• Considere el uso de una SSD, esta es una gran ganancia y son cada vez más baratas.

• más memoria puede tener un gran efecto a veces - (reducir la RAM en la máquina si se obtiene una gran frenar mediante la eliminación de un poco de RAM, puede obtener una gran velocidad mediante la adición de más)

• eliminar las referencias que no sean necesarios del proyecto (es posible que tenga que quitar “usings” innecesarios primero)