Velocidad de ejecución de la prueba unitaria (¿cuántas pruebas por segundo?)

Question

¿Qué tipo de tasa de ejecución pretendes 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 le perjudica?

Finalmente, cuando decide que las pruebas deben ejecutarse más rápido, ¿qué técnicas utiliza para acelerar sus pruebas?

Nota: las pruebas de integración obviamente son otra cosa. Estamos hablando estrictamente de pruebas unitarias que deben ejecutarse con la mayor frecuencia posible.

---

rodeo Respuesta: Gracias por las grandes respuestas hasta el momento. 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 bajo 10 segundos.

No estoy seguro de si es correcto para marcar una como una "respuesta aceptada" cuando están todos muy útil :)

Answer 1

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 regresa).

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.

Eso no significa que ignore la prueba de 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.

Answer 2

que tienden a centrarse más en la lectura de mis pruebas de que 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 compilación tome horas, momento en el que es más probable que se encuentre con una serie de pruebas lentas en lugar de una o dos pruebas que pueda Optimice fácilmente ... por lo tanto, probablemente debería prestar atención INMEDIATAMENTE si ve muchas pruebas corriendo cientos de milisegundos cada una (o peor, segundos cada una), en lugar de esperar hasta llegar a los cientos de pruebas que tomaron ese punto largo (en el cual señalar que va a ser muy difícil resolver el problema).

Aún así, solo reducirá el tiempo entre el momento en que la versión automatizada emite errores ... lo cual está bien si es una hora más tarde (o incluso unas pocas horas después), 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ó.

Answer 3

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.

Answer 4

Actualmente estamos en 270 pruebas en alrededor de 3 segundos. Probablemente haya alrededor de 8 pruebas que realicen archivos IO.

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 consumen 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 le toma más de unos segundos realizar cientos de pruebas, es posible que necesite examinar lo que está clasificando como una prueba de unidad y si sería mejor tratarla como una prueba de humo.

su kilometraje obviamente será muy variable dependiendo de su área de desarrollo.

Answer 5

Juzgo mis pruebas de unidad 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.

Answer 6

Hubo un good article en esto de Power Of Two games, los autores de UnitTest++.

Answer 7

Data Point - Python regresión Pruebas de

Éstos son los números en mi portátil para ejecutar "make test" para Python 2.5.2:

• número de pruebas: 3851 (aprox)
tiempo
• ejecución: 9 min, 6 sec
• ejecución tasa: 7 pruebas/seg

Answer 8

¿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 la prueba unitaria no es ralentizar, pero para llevar un mensaje "nada roto, continúe" (o "algo se rompió, STOP").

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.

Por último, cuando usted decide las pruebas necesidad de correr más rápido, ¿Qué técnicas que se utilizan para acelerar las pruebas?

primero que hay que hacer es gestionar para averiguar por qué son demasiado lento, y wether el problema está en las pruebas de la unidad o en el código que se está probando?

que iba a tratar de romper el banco de pruebas en varias partes lógicas, corriendo sólo la parte que es supuestamente afectados por el código he cambiado en cada compilación. Me gustaría ejecutar las otras suites con menos frecuencia, tal vez una vez al día, o en caso de duda podría haber roto algo, y al menos antes de integrar.

Answer 9

El objetivo es 100 s de pruebas por segundo. La forma de llegar es siguiendo el rules of unit tests de Michael Feather.

Un punto importante que surgió en el pasado CITCON es que si sus pruebas no son tan rápidas, es muy probable que no obtenga los beneficios de diseño de las pruebas unitarias.

Answer 10

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 guardo un modelo de Rails app/models/foo.rb, se ejecutan las pruebas de unidades correspondientes en test/unit/foo_test.rb.

No sé si existe algo similar para otras plataformas, pero tendría sentido.

Answer 11

Una de las reglas más importantes acerca de las pruebas unitarias es decir, deben ejecutar rápida.

¿Cuánto tiempo es demasiado largo para una prueba de unidad individual?

Los desarrolladores deben ser capaces de 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.

¿Qué tipo de tasa de ejecución pretendes con tus pruebas unitarias (# prueba por segundo)?

Debe 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 unas 800 pruebas que se ejecutan en menos de 30 segundos, unas 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 ralentizar nuestra construcción de integración continua.

También tenemos un límite de tiempo de espera configurable establecido en 5 segundos; todo lo que tarde más tiempo fallará.