Prueba de unidad post mortem

Question

Realizo control de versiones con Git, y pruebas de unidad con QUnit. A veces encuentro un error en mi software que no estaba presente en una versión anterior. Es fácil para mí escribir una prueba unitaria específicamente para ese error.

Dada esa prueba unitaria, ¿puedo pasar fácilmente por todas mis confirmaciones pasadas y probar la compilación con esa prueba unitaria, de modo que pueda determinar qué compromiso causó la rotura?

Answer 1

Utilice git bisect para esto, consulte this page.

Dado que está probando JavaScript, probablemente tenga que ejecutar las pruebas a mano y ejecutar git bisect good y git bisect bad según corresponda. Sin embargo, si se puede ejecutar la prueba de unidad de la línea de comandos, a continuación, puede utilizar git bisect run tener Git ejecutar la prueba en varias ocasiones y localizar el fallo se comprometen de forma automática:

$ git bisect run my-script.sh 

Eso es pura magia la primera vez que lo vea ! :-)

Answer 2

Usted describió el trabajo de git bisect. The Git Book tiene a good tutorial.

También hay cierta confusión en los términos de su pregunta: Cuando se utiliza una prueba para protegerse contra la re-introducción de errores previamente fijados o por la bisección del cochecito cometa, que se llama una prueba regresión, no un prueba unitaria. La última prueba es pura prueba si una pequeña unidad de código dada funciona, y está sujeta a grandes restricciones de tiempo (las personas TDD ejecutan pruebas unitarias varias docenas de veces en un día). Para un proyecto grande, generalmente tiene pruebas de regresión mucho más largas que las pruebas unitarias, por lo que es posible que desee obtener las categorías limpias.

Answer 3

Sí, esto se llama git bisect, y se introdujo por primera vez en git.

Principio:

• agarrar un cometió en el pasado donde se sabe que funcionó, vamos a llamarlo c1;
• tomar una confirmación después de c1 sabe que falla, llámelo c2;
• git bisect start c2 c1.

Incluso puede restringir el bisect a subtrazados si sabe dónde se produce un error, y si tiene un script que puede ejecutar la prueba no interactiva, utilice git bisect run.

Answer 4

Git tiene un comando para hacer exactamente lo que quiere, git bisect

Búsqueda por búsqueda binaria el cambio que se introdujo un error

En el caso de que desee utilizarlo como git bisect run /path/to/script, que probará automáticamente confirmaciones y realizará un control con cada confirmación para encontrar el incorrecto compromiso.

Tenga en cuenta que la secuencia de comandos (my_script en el ejemplo anterior) debe salir con código 0 si el código fuente de corriente es buena, y la salida con un código de entre 1 y 127 (inclusive), excepto 125, si la fuente de corriente el código es malo

Cualquier otro código de salida anulará el proceso de bisección. Cabe señalar que un programa que termina a través de "exit (-1)" deja $? = 255, (consulte la página de manual de salida (3)), ya que el valor está picado con "& 0377".

El código de salida especial 125 se debe utilizar cuando el código fuente actual no se puede probar. Si la secuencia de comandos sale con este código, se saltará la revisión actual (consulte la sección anterior de git bisect). Se eligió 125 como el valor sensible más alto para usar para este propósito, porque las cáscaras POSIX usan 126 y 127 para señalar el estado de error específico (127 es para comando no encontrado, 126 es para comando encontrado pero no ejecutable --- estos detalles sí no importa, ya que son errores normales en el script, en lo que se refiere a "bisect run").

Por lo tanto, su secuencia de comandos compilaría sus fuentes, ejecutará su unidad de prueba de unidad y luego dará el código de salida correspondiente. La sección de ejemplo del bisect manpage lo cubre muy bien (incluidas compilaciones rotas, fusiones de fusiones fusionadas, etc.)