Unidad de prueba de la velocidad de ejecución (cómo muchas pruebas por segundo?)

Question

¿Qué tipo de tasa de ejecución del hacer tu objetivo con su unidad de pruebas (# de prueba por segundo)?¿Cuánto tiempo es demasiado largo para una unidad individual de la prueba?

Yo estaría interesado en saber si la gente tiene alguna umbrales específicos para determinar si sus pruebas son demasiado lento, o es sólo cuando la fricción de una larga suite de prueba obtiene lo mejor de usted?

Por último, cuando se decide la prueba debe correr más rápido, qué técnicas utiliza para acelerar la velocidad de sus pruebas?

Nota:pruebas de integración son, obviamente, una cuestión diferente de nuevo.Estamos estrictamente hablando de la unidad de pruebas que se deben ejecutar con la mayor frecuencia posible.

---

Respuesta roundup: Gracias por la gran respuesta hasta el momento.La mayoría de los consejos que parece ser no te preocupes por la velocidad, concentrarse en la calidad y sólo ejecutar de forma selectiva si ellos son demasiado lentos.Respuestas con números específicos han incluido buscando <10ms hasta 0,5 y 1 segundo por cada prueba, o simplemente a mantener el conjunto de la comúnmente ejecutar las pruebas de menos de 10 segundos.

No estoy seguro si es correcto para marcar a uno como "aceptado respuesta" cuando todos son de gran ayuda :)

Answer 1

Todos los tests se deben ejecutar en menos de un segundo (que es toda unidad de pruebas combinadas deben ejecutar en 1 segundo).Ahora estoy seguro de que este tiene límites prácticos, pero he tenido un proyecto con un 1000 pruebas que se ejecutarán este rápido en un ordenador portátil.Usted realmente quiere que esta velocidad por lo que sus desarrolladores no temen la refactorización de algunas de las partes esenciales del modelo (es decir, Déjame ir a buscar un poco de café mientras corro estas pruebas...10 minutos más tarde, él viene de vuelta).

Este requisito también te obliga a diseñar la aplicación correctamente.Esto significa que el modelo de dominio es puro y no contiene referencias a cualquier tipo de persistencia (e/S de Archivos, Base de datos, etc).Las pruebas unitarias son todos acerca de las pruebas de los negocios relatonships.

Ahora bien, eso no significa ignorar las pruebas de su base de datos o la persistencia.Pero estos problemas son ahora aislado detrás de los repositorios que puede ser probado por separado con las pruebas de integración que se encuentra en un proyecto independiente.Ejecutar pruebas unitarias constantemente a la hora de escribir código de dominio y, a continuación, ejecute las pruebas de integración una vez en el check in.

Answer 2

Si estamos hablando estrictamente de la unidad de pruebas, me gustaría apuntar más para la integridad de la velocidad.Si el tiempo de ejecución se inicia a causa de la fricción, separado de la prueba en los diferentes proyectos/clases etc., y sólo ejecuta las pruebas relacionadas con lo que estás trabajando.Dejar que el servidor de Integración ejecutar todas las pruebas en el checkin.

Answer 3

El objetivo es 100s de pruebas por segundo.La manera de llegar allí es por la siguiente Michael Pluma reglamento de las pruebas de unidad.

Un punto importante que ocurrió en un pasado CITCON la discusión es que si las pruebas no son tan rápido que es muy probable que usted no está recibiendo el diseño de los beneficios de las pruebas unitarias.

Answer 4

Tienden a centrarse más en mejorar la legibilidad de mis pruebas de velocidad.Sin embargo, sigo tratando de hacer razonablemente rápido.Creo que si se ejecutan en el orden de los milisegundos, tú estás bien.Si se ejecuta un segundo o más por probar...entonces usted podría estar haciendo algo que debe ser optimizado.

Lento pruebas sólo se convierten en un problema a medida que madure el sistema y las causas de la generación para tomar horas, momento en el que es más probable un problema de una gran cantidad de tipo de lento pruebas en lugar de uno o 2 pruebas de que se puede optimizar fácilmente...por lo tanto, usted probablemente debería prestar atención de inmediato si usted ve un montón de pruebas se ejecutan cientos de milisegundos cada uno (o peor, segundos cada uno), en vez de esperar hasta que llegue a los cientos de pruebas teniendo que long point (punto en el que va a ser muy duro para resolver el problema).

Aun así, se reducirá el tiempo entre el momento de su generación automática de problemas de errores...que está bien si es una hora más tarde (o incluso un par de horas más tarde), creo.El problema está ejecutando antes de check-in, pero esto puede ser evitado mediante la selección de un pequeño subconjunto de pruebas para que se refieren a lo que usted está trabajando.Sólo asegúrese de fijar la build si usted comprobar en el código que rompe las pruebas que no se ejecuta!

Answer 5

Actualmente estamos en 270 pruebas en alrededor de 3.algo segundos.Hay, probablemente, alrededor de las 8 pruebas que realizar e / s de archivos.

Estos se ejecutan de forma automática tras una exitosa generación de nuestras bibliotecas en todos los ingenieros de la máquina.Tenemos más extensa (y consume mucho tiempo) de humo pruebas que se hacen por la construcción de la máquina cada noche, o puede ser iniciado manualmente en un ingenieros de la máquina.

Como se puede ver no hemos alcanzado todavía el problema de las pruebas que consumen demasiado tiempo.10 segundos para mí es el punto donde empieza a ser intrusivo, cuando empezamos a enfoque que va a ser algo que vamos a echar un vistazo a.Estamos más probable es que se mueva el nivel inferior de las bibliotecas, que son más fuertes, ya que cambian con poca frecuencia y tienen pocas dependencias, en la nightly builds, o una configuración donde sólo son ejecutados por el equipo de generación.

Si usted encuentra que está tomando más de un par de segundos para ejecutar un centenar de pruebas que usted podría necesitar para examinar lo que está clasificando como una unidad de prueba y si no sería mejor tratada como una prueba de humo.

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

Answer 6

Los Datos De Punto -- De Python Pruebas De Regresión

Aquí están los números en mi ordenador portátil para la ejecución de "hacer la prueba" 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.

Answer 7

Yo juzgo a mi unidad de pruebas en un por base de pruebas selectivas, no por # de pruebas por segundo.La tasa que pretende es 500ms o menos.Si está por encima de eso, voy a mirar en la prueba para averiguar por qué está tomando tanto tiempo.

Cuando pienso en una prueba es lento, por lo general significa que se está haciendo demasiado.Por lo tanto, sólo la refactorización de la prueba, dividiéndolo en más pruebas que generalmente se hace el truco.Las otras veces que me he dado cuenta de que mis pruebas de funcionamiento lento es cuando la prueba muestra un cuello de botella en mi código, a continuación, una refactorización del código está en orden.

Answer 8

Hubo un buen artículo en esto de Poder De los Dos partidos, los autores de UnitTest++.

Answer 9

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

Yo diría que depende de la compilación de velocidad.Por lo general ejecuta las pruebas en cada compilación.El objetivo de la unidad de pruebas no es a disminuir, pero para llevar un mensaje "nada roto, vaya"(o "algo se rompió, PARADA de").

No me molesta acerca de la ejecución de prueba de velocidad hasta que esto es algo que empieza a ser molesto.

El peligro es para detener la ejecución de las pruebas debido a que son demasiado lento.

Finalmente, cuando usted decide las pruebas necesidad de correr más rápido, lo que las técnicas de hacer se utiliza para acelerar la velocidad de sus pruebas?

La primera cosa a hacer es conseguir averiguar por qué ellos son demasiado lentos, y si el problema está en la unidad de pruebas o en el código bajo prueba ?

Me gustaría probar a romper la suite de prueba en varias partes lógicas, ejecuta sólo la parte que es supuestamente afectados por el código que he cambiado en cada compilación.Me gustaría ejecutar las otras suites con menos frecuencia, tal vez una vez al día, o cuando la duda me podría haber roto algo, y al menos antes de la integración de.

Answer 10

Algunos marcos de proporcionar la ejecución automática de los específicos de la unidad de pruebas basadas en heurísticas tales como la hora de última modificación.Para Ruby y Rails, AutoTest, ofrece mucho más rápido y sensible de la ejecución de las pruebas-cuando puedo guardar un modelo de Rieles app/models/foo.rb, las correspondientes pruebas de unidad en test/unit/foo_test.rb consigue correr.

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

Answer 11

Una de las reglas más importantes acerca de la unidad de pruebas es que se debe ejecutar rápido.

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

Los desarrolladores deben ser capaces de ejecutar toda la suite de pruebas de unidad en segundos y no en minutos y los minutos.Los desarrolladores deben ser capaces de ejecutar rápidamente a ellos después de cambiar el código de todos modos.Si se toma demasiado tiempo, que no se molestan en ejecución ellos y se pierde uno de los principales beneficios de las pruebas.

¿Qué tipo de tasa de ejecución del hacer tu objetivo con su unidad de pruebas (# de prueba por segundo)?

Usted debe apuntar para cada prueba a ejecutar en un orden de milisegundos, algo más de 1 segundo es probablemente demasiadas pruebas.

Actualmente tenemos alrededor de 800 pruebas que se ejecutan en menos de 30 segundos, alrededor de 27 pruebas por segundo.Esto incluye el tiempo para lanzar el emulador móvil necesario para ejecutarlas.La mayoría de ellos toman cada 0-5ms (si mal no recuerdo).

Tenemos uno o dos que tienen alrededor de 3 segundos, que son probablemente los candidatos para comprobar, pero lo importante es que todo el conjunto de pruebas no toma tanto tiempo, que pone a los desarrolladores de ejecutarlo, y no ralentizar considerablemente nuestra compilación de integración continua.

También tenemos un configurables límite de tiempo de espera de 5 segundos-nada que no va a fallar.