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

Tengo alrededor de 100 pruebas unitarias y con una cobertura de% 20, que estoy tratando de aumentar la cobertura y también este es un proyecto en desarrollo, así que sigue agregando nuevas pruebas.¿Cómo lidiar con las pruebas unitarias de larga ejecución?

Actualmente, realizar mis pruebas después de que cada compilación no es posible demoran aproximadamente 2 minutos.

prueba incluye:

de archivos de lectura de las carpetas de prueba (estilo basado en datos para simular algunas cosas HTTP)
Hacer peticiones HTTP reales a un servidor web local (esto es un gran dolor para simulacro, así que no lo haré)
No todas son pruebas unitarias, pero también hay clases de subprocesos múltiples bastante complicadas que deben ser probadas y yo pruebo el comportamiento general de la prueba. Que se puede considerar como Prueba funcional, pero también se debe ejecutar cada vez.

La mayor parte de la funcionalidad requiere leer HTTP, hacer TCP, etc. No puedo cambiarlos porque esa es toda la idea del proyecto, si cambio estas pruebas será inútil probar cosas.

Además, no creo tener las herramientas más rápidas para ejecutar las pruebas unitarias. Mi configuración actual usa VS TS con Gallio y nUnit como marco. Creo que VS TS + Gallio es un poco más lento que otros también.

¿Qué recomiendas para solucionar este problema? Quiero ejecutar pruebas unitarias luego de que cada pequeño cambio de BTU, actualmente este problema está interrumpiendo mi flujo.

más aclaraciones Editar:

código es altamente acoplado! Lamentablemente, cambiar es como un gran proceso de refracción. Y hay un síndrome de huevo de gallina en el que necesito pruebas unitarias para refactorizar un código tan grande, pero no puedo tener más pruebas de unidad si no lo refactorizo :)

Código altamente acoplado no me permite para dividir las pruebas en trozos más pequeños. Además, no pruebo cosas privadas, es una elección personal, que me permite desarrollarme mucho más rápido y aun así obtener una gran cantidad de beneficios.

Y puedo confirmar que todas las pruebas unitarias (con el aislamiento adecuado) son bastante rápidas en realidad, y no tengo un problema de rendimiento con ellas.

más aclaraciones:

Y puedo confirmar que todas las pruebas unitarias (con el aislamiento adecuado) son bastante rápidas en realidad, y no tengo un problema de rendimiento con ellas.

Fuente

2008-12-15 dr. evil

No me parecen pruebas unitarias, sino más bien pruebas funcionales. Está bien, automatizar las pruebas funcionales es bueno, pero es bastante común que las pruebas funcionales sean lentas. Están probando todo el sistema (o piezas grandes).

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

¿Puede decirme qué pruebas tiene, cuáles son pruebas unitarias (solo prueba 1) frente a pruebas funcionales (prueba 2 o más cosas al mismo tiempo)? ¿Cuáles son rápidos y cuáles son lentos?

Fuente

2008-12-15 15:06:32

Así que supongo que el movimiento correcto sería: refactorizar el código de una manera en la que no tengo tanto acoplamiento. ¿Luego ejecutas pruebas funcionales diariamente pero ejecutas pruebas unitarias después de cada compilación? –

También he actualizado la pregunta con respecto a su respuesta. –

Incluso podría ejecutar todas las pruebas funcionales en cada registro con integración continua. Cuando estoy escribiendo pruebas unitarias, tiendo a ejecutar las locales con respecto a las que estoy trabajando con mucha frecuencia, luego series más grandes con menos frecuencia y todo antes de comprometerme. –

Puede dividir sus pruebas en dos grupos, uno para pruebas cortas y otro para pruebas de larga ejecución, y ejecutar las pruebas de larga duración con menos frecuencia mientras ejecuta las pruebas cortas después de cada cambio. Aparte de eso, burlarse de las respuestas del servidor web y otras solicitudes que hace su aplicación conducirían a una prueba más corta.

Fuente

2008-12-15 15:07:11

Primero, esas no son pruebas unitarias.

No hay mucho más que hacer pruebas funcionales como esas después de cada cambio pequeño. Después de un cambio considerable, querrá ejecutar sus pruebas funcionales.

En segundo lugar, no tenga miedo de burlarse de la parte Http de la aplicación. Si realmente desea probar la aplicación, es IMPRESCINDIBLE. Si no estás dispuesto a hacer eso, vas a perder mucho más tiempo tratando de probar tu lógica real, esperando que las solicitudes HTTP regresen e intentes configurar los datos.

Mantendré las pruebas de nivel de integración, pero me esfuerzo por crear pruebas de unidades reales. Esto resolverá tus problemas de velocidad. Las pruebas de unidades reales no tienen interacción DB, o interacción HTTP.

Fuente

2008-12-15 15:39:47

Siempre uso una categoría para "LongTest". Esas pruebas se ejecutan todas las noches y no durante el día. De esta manera puede reducir mucho el tiempo de espera. Pruébalo: clasifica tu unidad de prueba.

Fuente

2008-12-15 15:42:37

Creo que necesito jugar con los paneles de VS TS, normalmente uso NUnit pero de alguna manera después de las actualizaciones finales de .NET Framework, la GUI de NUnit no funciona, así que me quedé con la estúpida prueba de MS Suite y Gallio. –

Parece que también debe manejar las expectativas del equipo de desarrollo.

Supongo que las personas hacen varias compilaciones por día y se ejecutan para ejecutar pruebas después de cada compilación. Es posible que estemos bien servidos para cambiar su cronograma de pruebas para ejecutar una compilación con pruebas durante el almuerzo y luego otra durante la noche.

Estoy de acuerdo con Brad en que estas parecen pruebas funcionales. Si puedes separar el código, sería genial, pero hasta entonces cambiaría a pruebas menos frecuentes.

Fuente

2008-12-15 15:43:55 Bryan

Actualmente, eso es lo que estoy haciendo. Simplemente ejecuta pruebas unitarias alrededor de 3 veces en un día. –

recomendaría un enfoque combinado para su problema:

pasan con frecuencia un subconjunto de las pruebas que se acercan del código se realizan cambios a (por ejemplo, pruebas de un mismo paquete, módulo o similar) . Con menos frecuencia ejecuta pruebas que están más alejadas del código en el que está trabajando actualmente.
Divida su suite en al menos dos: pruebas de ejecución rápida y de ejecución lenta. Ejecute las pruebas de ejecución rápida con más frecuencia.
Considere la posibilidad de que algunas de las pruebas con probabilidad de fallo menor solo las ejecute un servidor de integración continua automatizado.
Aprenda técnicas para mejorar el rendimiento de sus pruebas.Lo más importante es reemplazar el acceso a los recursos del sistema lento por falsificaciones más rápidas. Por ejemplo, use en secuencias de memoria en lugar de archivos. Probar/burlarse del acceso http. etc.
Aprenda a usar las técnicas de reducción de dependencia de bajo riesgo, como las que se enumeran en el libro (muy recomendable) "Trabajar eficazmente con código heredado". Esto le permite hacer que su código sea más comprobable sin aplicar refactorizaciones de alto riesgo (a menudo empeorando temporalmente el diseño real, 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 habrá dolor. Todo lo que puede hacer es aceptar ese hecho y hacer todo lo posible para salir lentamente del desorden.

Fuente

2008-12-15 15:51:59

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

Respuesta

Cuestiones relacionadas