¿Cómo lidiar con las pruebas unitarias de larga ejecución?

Question

Tengo alrededor de 100 pruebas de unidad y con una cobertura del 20%, lo que estoy tratando de aumentar la cobertura y también esto es un proyecto en desarrollo a fin de seguir añadiendo nuevas pruebas.

Actualmente en ejecución mis pruebas después de cada generación no es factible que dura aproximadamente 2 minutos.

prueba incluye:

• archivos de lectura de las carpetas de prueba (estilo por datos para simular algunas cosas HTTP)
• Hacer peticiones HTTP reales a un servidor web local (esto es un dolor enorme para burlarse, así que no lo hará)
• No todos ellos unidad de pruebas, pero también hay clases de multiproceso bastante complicados que necesitan ser probado y que hago probar el comportamiento global de la prueba. Que se puede considerar como pruebas funcionales, pero necesitan que se ejecute cada vez que así.

La mayor parte de la funcionalidad HTTP requiere la lectura, haciendo TCP, etc. No puedo cambiarlos, porque esa es la idea de proyecto si cambio de estas pruebas que será inútil para probar cosas.

Además no creo que tenga las herramientas más rápidas para ejecutar pruebas unitarias. Mi configuración actual utiliza VS TS con Galio y nUnit como marco. Creo VS TS + Galio es un poco más lento que los demás.

¿Qué me recomiendan para solucionar este problema? Quiero correr unidad de pruebas después de cada poco cambia btu Actualmente este problema está interrumpiendo mi flujo.

más aclaraciones Editar:

El código es altamente acoplada! Por desgracia y el cambio es como un gran proceso de refatoring. Y hay un síndrome de huevo de gallina en ella donde necesito pruebas de unidad de refactorizar un código tan grande pero no pueden tener más pruebas de unidad si no refactorearlo:)

código

altamente acoplada no me permite a dividir en partes más pequeñas pruebas. Además no probar cosas privadas, es una elección personal, que me permiten desarrollar de manera mucho más rápida y todavía ganar una gran cantidad de beneficios.

Y puedo confirmar que todas las pruebas unitarias (con el aislamiento adecuado) en realidad bastante rápido, y yo no tienen un problema de rendimiento con ellos.

---

más aclaraciones:

El código es altamente acoplada! Por desgracia y el cambio es como un gran proceso de refatoring. Y hay un síndrome de huevo de gallina en ella donde necesito pruebas de unidad de refactorizar un código tan grande pero no pueden tener más pruebas de unidad si no refactorearlo:)

código

altamente acoplada no me permite a dividir en partes más pequeñas pruebas. Además no probar cosas privadas, es una elección personal, que me permiten desarrollar de manera mucho más rápida y todavía ganar una gran cantidad de beneficios.

Y puedo confirmar que todas las pruebas unitarias (con el aislamiento adecuado) en realidad bastante rápido, y yo no tienen un problema de rendimiento con ellos.

Answer 1

Estos no suenan como las pruebas de unidad a mí, sino más bien como pruebas funcionales. Eso está bien, la automatización de pruebas funcionales es buena, pero es bastante común para pruebas funcionales que lento. Están probando todo el sistema (o grandes piezas de la misma).

Las pruebas unitarias tienden a ser rápido porque están probando una cosa aislada de todo lo demás. Si no puede probar las cosas de manera aislada de todo lo demás, se debe considerar que una señal de advertencia de que el código es demasiado fuertemente acoplado .

Se puede decir que prueba que tienes que son pruebas de unidad de prueba (1 cosa solamente) frente a las pruebas funcionales (prueba 2 o más cosas a la vez)? Cuáles son rápidos y cuáles son lentos?

Answer 2

Se podría dividir sus pruebas en dos grupos, uno para pruebas cortas y otro para las pruebas de larga duración, y ejecute las pruebas de larga duración con menor frecuencia durante la ejecución de las pruebas cortas después de cada cambio. Aparte de eso, burlándose de las respuestas de los servidores web y otras peticiones de sus marcas de aplicaciones puedan dar lugar a una menor ejecución de prueba.

Answer 3

Yo recomendaría un enfoque combinado a su problema:

• pasan con frecuencia un subconjunto de las pruebas que se acercan del código se realizan cambios en las pruebas (por ejemplo desde el mismo paquete, módulo o similar). Con menor frecuencia las pruebas que se eliminan más lejos del código que se está trabajando actualmente en la gestión.
• Dividir su suite en al menos dos: carrera rápida y las pruebas que se ejecutan lentamente. Ejecutar las pruebas de funcionamiento rápido con más frecuencia.
• Considere hacer que algunos de los menos propensos a fallar pruebas sólo ser ejecutadas por un servidor de integración automatizado continúa.
• Aprender técnicas para mejorar el rendimiento de sus pruebas. Lo más importante es mediante la sustitución de acceso a los recursos del sistema lento por falsificaciones más rápidos. Por ejemplo, el uso de la memoria en lugar de flujos de archivos. Stub / burlarse del acceso HTTP. etc.
• Aprende a utilizar las técnicas de baja dependencia de riesgos romper, como los que se enumeran en el libro (muy recomendado) "trabajar eficazmente con el código heredado". Estos le permiten realizar eficazmente su código sea más comprobable sin aplicar refactorizaciones de alto riesgo (a menudo haciendo temporalmente el diseño actual es peor, como romper la encapsulación, hasta que pueda refactorizar a un mejor diseño con la red de seguridad de las pruebas).

Una de las cosas más importantes que aprendí del libro mencionado anteriormente: no hay magia, trabajando con el código heredado es dolor, y siempre será dolor. Todo lo que puedes hacer es aceptar ese hecho, y hacer lo mejor para trabajar lentamente su manera de salir del lío.

Answer 4

En primer lugar, esos no son pruebas unitarias.

No hay mucho de un punto de la ejecución de pruebas funcionales como que después de cada cambio pequeño. Después de un cambio importante que tendrá que ejecutar las pruebas funcionales.

En segundo lugar, no tenga miedo de burlarse de la parte HTTP de la aplicación. Si realmente quiere unidad de prueba de la aplicación es un deber. Si no está dispuesto a hacer eso, usted va a perder mucho más tiempo tratando de poner a prueba su lógica real, a la espera de peticiones HTTP para volver y tratar de establecer los datos.

Me gustaría mantener sus pruebas de nivel de integración, pero se esfuerzan por crear pruebas unitarias reales. Esto va a resolver sus problemas de velocidad. pruebas de unidad real no tienen interacción DB, o la interacción HTTP.

Answer 5

Yo siempre uso una categoría para "LongTest". Aquellos prueba se ejecuta cada noche y no durante el día. De esta manera se puede reducir el tiempo de espera por una gran cantidad. Inténtelo:. Categoría de su unidad de pruebas

Answer 6

Parece que puede que tenga que manejar las expectativas entre el equipo de desarrollo también.

Asumo que la gente está haciendo varias construye por día y se epxected para ejecutar las pruebas después de cada generación. Es posible que bien servido para cambiar su calendario de pruebas para ejecutar una acumulación de pruebas durante el almuerzo y luego otro durante la noche.

Estoy de acuerdo con Brad que éstas suenan como las pruebas funcionales. Si puede sacar el código aparte que sería grande, pero hasta entonces me gustaría cambiar a las pruebas menos frecuentes.