unit-testing - test - tipos de pruebas unitarias
Velocidad de ejecución de la prueba unitaria(¿cuántas pruebas por segundo?) (11)
¿A qué tipo de tasa de ejecución aspiras con tus pruebas unitarias (# prueba por segundo)? ¿Cuánto tiempo es demasiado largo para una prueba de unidad individual?
Me interesaría saber si las personas tienen umbrales específicos para determinar si sus pruebas son demasiado lentas, ¿o es solo cuando la fricción de un conjunto de pruebas de larga ejecución te perjudica?
Finalmente, cuando decide que las pruebas deben ejecutarse más rápido, ¿qué técnicas usa para acelerar sus pruebas?
Nota: las pruebas de integración obviamente son una cuestión diferente nuevamente. Estamos hablando estrictamente de pruebas unitarias que deben ejecutarse con la mayor frecuencia posible.
Resumen de respuesta: gracias por las excelentes respuestas hasta ahora. La mayoría de los consejos parece ser que no se preocupe por la velocidad: concéntrese en la calidad y simplemente adminístrelos de forma selectiva si son demasiado lentos. Las respuestas con números específicos han incluido apuntar a <10ms hasta 0.5 y 1 segundo por prueba, o simplemente mantener todo el conjunto de pruebas comunes en menos de 10 segundos.
No estoy seguro de si es correcto marcar una como una "respuesta aceptada" cuando todos son útiles :)
Actualmente estamos en 270 pruebas en alrededor de 3.algunos segundos. Probablemente haya alrededor de 8 pruebas que realicen archivos IO.
Estos se ejecutan automáticamente después de una compilación exitosa de nuestras bibliotecas en cada máquina de ingenieros. Tenemos pruebas de humo más extensas (y lentas) que la máquina de construcción realiza todas las noches o que se pueden iniciar manualmente en una máquina de ingenieros.
Como puede ver, todavía no hemos llegado al problema de que las pruebas consuman demasiado tiempo. 10 segundos para mí es el punto en el que comienza a volverse intrusivo, cuando comenzamos a acercarnos será algo que veremos. Es probable que traslademos las bibliotecas de nivel inferior, que son más sólidas ya que cambian con poca frecuencia y tienen pocas dependencias, a las compilaciones nocturnas, o una configuración en la que solo las ejecuta la máquina de compilación.
Si considera que le llevará más de unos pocos segundos realizar cientos de pruebas, es posible que deba examinar lo que está clasificando como una prueba unitaria y si se trataría mejor como una prueba de humo.
su kilometraje obviamente será muy variable dependiendo de su área de desarrollo.
Juzgo mis pruebas unitarias por prueba, no por # de pruebas por segundo. La tasa que pretendo es de 500 ms o menos. Si está por encima de eso, examinaré la prueba para descubrir por qué me está tomando tanto tiempo.
Cuando creo que una prueba es lenta, generalmente significa que está haciendo demasiado. Por lo tanto, simplemente refactorizar la prueba dividiéndola en más pruebas suele ser el truco. Las otras veces que noté que mis pruebas se ejecutan lentamente es cuando la prueba muestra un cuello de botella en mi código, luego una refactorización del código está en orden.
Si hablamos estrictamente de pruebas unitarias, apuntaría más a la integridad que a la velocidad. Si el tiempo de ejecución comienza a causar fricción, separe la prueba en diferentes proyectos / clases, etc., y solo ejecute las pruebas relacionadas con lo que está trabajando. Deje que el servidor de integración ejecute todas las pruebas al registrarse.
Tiendo a enfocarme más en la legibilidad de mis pruebas que en la velocidad. Sin embargo, aún trato de hacerlos razonablemente rápidos. Creo que si se ejecutan en el orden de milisegundos, estás bien. Si ejecutan un segundo o más por prueba ... entonces es posible que esté haciendo algo que debería optimizarse.
Las pruebas lentas solo se convierten en un problema a medida que el sistema madura y hace que la construcción tarde horas, en ese punto es más probable que te encuentres con una gran cantidad de pruebas lentas en lugar de una o dos pruebas que puedes optimizar fácilmente. Por lo tanto, probablemente debas prestar atención INMEDIATAMENTE si ves muchas pruebas que corren cientos de milisegundos cada una (o peor, segundos cada una), en lugar de esperar hasta que lleguen a los cientos de pruebas que toman ese punto largo (en qué punto va ser realmente difícil de resolver el problema).
Aún así, solo reducirá el tiempo entre el momento en que la construcción automatizada emite errores ... lo cual está bien si es una hora más tarde (o incluso unas pocas horas más tarde), creo. El problema es ejecutarlos antes de realizar el check-in, pero esto se puede evitar seleccionando un pequeño subconjunto de pruebas para ejecutar que estén relacionadas con lo que está trabajando. Solo asegúrate de arreglar la construcción si marcas el código que rompe las pruebas que no ejecutó.
Hubo un buen artículo sobre esto de Power Of Two games, los autores de UnitTest ++ .
Punto de datos - Pruebas de regresión de Python
Aquí están los números en mi computadora portátil para ejecutar "make test" para Python 2.5.2:
- número de pruebas: 3851 (aprox)
- tiempo de ejecución: 9 min, 6 sec
- tasa de ejecución: 7 pruebas / seg
Todas las pruebas unitarias deben ejecutarse en menos de un segundo (es decir, todas las pruebas unitarias combinadas deben ejecutarse en 1 segundo). Ahora estoy seguro de que esto tiene límites prácticos, pero he tenido un proyecto con 1000 pruebas que se ejecutan tan rápido en una computadora portátil. Realmente querrás esta velocidad para que tus desarrolladores no teman refaccionar una parte central del modelo (es decir, déjame tomar un café mientras realizo estas pruebas ... 10 minutos más tarde vuelve).
Este requisito también lo obliga a diseñar su aplicación correctamente. Significa que su modelo de dominio es puro y no contiene referencias a ningún tipo de persistencia (File I / O, Database, etc.). Las pruebas unitarias tienen que ver con probar esas relaciones comerciales.
Ahora eso no significa que ignore probar su base de datos o persistencia. Pero estos problemas ahora están aislados detrás de repositorios que se pueden probar por separado con pruebas de integración que se ubican en un proyecto separado. Ejecuta las pruebas de su unidad constantemente al escribir el código de dominio y luego ejecuta las pruebas de integración una vez en el registro.
El objetivo es 100 s de pruebas por segundo. La forma de llegar es siguiendo las reglas de pruebas unitarias de Michael Feather.
Un punto importante que surgió en una discusión pasada de CITCON es que si sus pruebas no son tan rápidas, es bastante probable que no obtenga los beneficios de diseño de las pruebas unitarias.
¿Cuánto tiempo es demasiado largo para una prueba de unidad individual?
Yo diría que depende de la velocidad de compilación. Uno generalmente ejecuta las pruebas en cada compilación. El objetivo de las pruebas unitarias no es desacelerar, sino traer un mensaje " nada roto, continuar " (o " algo se rompió, DETENER ").
No me preocupo por la velocidad de ejecución de la prueba hasta que esto es algo que comienza a ser molesto.
El peligro es dejar de ejecutar las pruebas porque son demasiado lentas.
Finalmente, cuando decide que las pruebas deben ejecutarse más rápido, ¿qué técnicas usa para acelerar sus pruebas?
Lo primero que debe hacerse es averiguar por qué son demasiado lentos y si el problema está en las pruebas unitarias o en el código bajo prueba.
Trataría de romper el conjunto de pruebas en varias partes lógicas, ejecutando solo la parte que supuestamente se ve afectada por el código que modifiqué en cada compilación. Corrí las otras suites con menos frecuencia, quizás una vez al día, o cuando tenía dudas podría haber roto algo, y al menos antes de integrarme .
Algunos marcos proporcionan la ejecución automática de pruebas unitarias específicas basadas en la heurística, como la hora de la última modificación. Para Ruby and Rails, AutoTest proporciona una ejecución mucho más rápida y receptiva de las pruebas: cuando app/models/foo.rb una app/models/foo.rb modelo de Rails, se app/models/foo.rb las pruebas unitarias correspondientes en test/unit/foo_test.rb .
No sé si existe algo similar para otras plataformas, pero tendría sentido.
Una de las reglas más importantes sobre las pruebas unitarias es que deben funcionar rápido .
¿Cuánto tiempo es demasiado largo para una prueba de unidad individual?
Los desarrolladores deberían poder ejecutar todo el conjunto de pruebas unitarias en segundos, y definitivamente no en minutos ni minutos. Los desarrolladores deberían poder ejecutarlos rápidamente después de cambiar el código de todos modos. Si lleva demasiado tiempo, no se molestarán en ejecutarlos y perderá uno de los principales beneficios de las pruebas.
¿A qué tipo de tasa de ejecución aspiras con tus pruebas unitarias (# prueba por segundo)?
Debería apuntar a que cada prueba se ejecute en un orden de milisegundos, cualquier cosa de más de 1 segundo probablemente esté probando demasiado.
Actualmente tenemos alrededor de 800 pruebas que se ejecutan en menos de 30 segundos, alrededor de 27 pruebas por segundo. Esto incluye el momento de lanzar el emulador móvil necesario para ejecutarlos. La mayoría de ellos toma de 0 a 5 ms (si no recuerdo mal).
Tenemos uno o dos que demoran unos 3 segundos, que probablemente sean candidatos para la verificación, pero lo importante es que el conjunto de pruebas completo no demora tanto en posponer a los desarrolladores que lo ejecutan, y no ralentiza de manera significativa nuestro continuo construcción de integración.
También tenemos un límite de tiempo de espera configurable establecido en 5 segundos; todo lo que tarde más tiempo fallará.