Los cambios que tocan pruebas y código a la vez se revierten con menos frecuencia que los cambios de tamaño similar que solo tocan código

Hipótesis

Los repositorios registran sus propias rectificaciones: la documentación de git revert la describe como el registro de nuevos commits que revierten el efecto de otros anteriores, y los commits correctivos suelen referirse en su mensaje al cambio que corrigen. La hipótesis es que, entre cambios de tamaño similar en la misma área de una base de código, los que añaden o modifican archivos de prueba junto con el código de producción se revierten o corrigen dentro de una ventana corta con menos frecuencia que los cambios que solo tocan código de producción. El mecanismo propuesto no es que las pruebas detecten todos los errores, sino que escribir o ajustar una prueba obliga al autor a establecer qué debe hacer el cambio y a ejecutarlo una vez de esa forma, lo cual elimina antes de la revisión una clase de errores (rama equivocada, valor por defecto equivocado, punto de llamada olvidado).

Predicción

En un repositorio con una batería de pruebas funcional, la proporción de cambios seguidos dentro de una ventana definida (por ejemplo, 14 días) por una reversión de ese cambio, o por un commit cuyo mensaje lo referencia como una corrección, es menor para los cambios que incluyen modificaciones de archivos de prueba que para los cambios que solo tocan código, tras emparejar por líneas modificadas, archivos tocados y directorio. Se espera que la diferencia sea menor para cambios triviales (renombrados, ediciones de comentarios) y mayor para cambios en lógica con ramificaciones. Los cambios que solo tocan archivos de prueba quedan excluidos de ambos grupos.

Prueba propuesta

1. Seleccionar repositorios con una batería de pruebas que se ejecute en CI y un historial de al menos un año; definir los archivos de prueba mediante un patrón de ruta por repositorio.
2. Para cada cambio que no sea un merge, registrar el tamaño, los archivos, el directorio, si se modificaron archivos de prueba y el autor.
3. Identificar los cambios "lamentados": un git revert posterior del cambio, o un commit dentro de la ventana cuyo mensaje referencia el identificador del cambio con una redacción propia de una corrección; registrar la regla de detección.
4. Emparejar los cambios que solo tocan código con los que tocan código y pruebas por tamaño y directorio; comparar las tasas de cambios lamentados con un intervalo, y repetir el análisis por repositorio en lugar de agruparlos todos juntos.
5. Informar la proporción de cambios que tocaron pruebas en algún grado, ya que un repositorio en el que casi todos los cambios lo hacen no ofrece contraste.

Estado

No se afirma ningún resultado. Las reversiones son una señal limitada: muchos cambios defectuosos se corrigen hacia adelante sin ninguna referencia, y algunas reversiones no tienen nada que ver con defectos (una función retirada por razones de producto). El emparejamiento por tamaño es esencial porque los cambios más grandes tienen a la vez más probabilidad de incluir pruebas y más probabilidad de ser revertidos, lo cual podría producir un resultado espurio en cualquiera de los dos sentidos.