Método alternativo para hacer Regtests más rápido
Los Regression Testings (Regtests para los amigos) son muy importantes a la hora de cazar fallos en el código, pues nos ayudan a encontrar el guilty commit que introdujo la(s) regresion(es) y así nos permiten ayudar al desarrollador a que pueda corregir aquello que estaba mal y despejar unos cuantos problemas a futuro.
Una de las principales metodologías para hacer los regtestings es la denominada búsqueda binaria o Bisecting, ésta se basa en calcular el número de revisiones entre la última buena y la primera mala conocidas, dividirlo para dos y sumarlo al primer número, obtenido éste se procede a verificar si en dicha revisión está presente o no el bug. Se repite el mismo proceso hasta que encontremos 2 versiones consecutivas donde una sea buena y la siguiente mala, la que será efectivamente la guilty commit.
Tanto GIT como Fossil ofrecen un comando que ayuda a llevar un registro de la búsqueda binaria, pero existe un problema: matemáticamente vas a tener que testear al menos el 25% del rango total, digamos que hay 1000 versiones entre el rango de buena-mala, deberás hacer como mínimo 250 testeos sí o sí, es por esa razón que hoy propongo otro método que me da resultados en muchos menos testeos.
Éste método es en la práctica una búsqueda binaria basada en fechas y es muy simple de aplicar, de hecho el siguiente ejemplo es un regtesting real: primero comienzo con un bug detectado en las últimas revisiones del repositorio en Septiembre del 2021, entonces procedo a buscar el año en que se agregó, para el efecto tomo la primera revisión de cada año y testeo. Preferí iniciar con el año 2017, 2018 y 2019 todas buenas, 2020 mala. Vamos hasta acá 4 testeos.
Confirmado que el fallo se introdujo en 2019, tomo la primera revisión del segundo semestre, es decir el 1 de Julio: mala, tomo la primera revisión del segundo trimestre, 1 de Abril: mala, ahora he reducido el rango a solo 3 meses, tomo la primera revisión de Febrero: buena, revisión del 1 de Marzo: mala, hasta acá llevamos apenas 8 testeos.
Reducido el rango a un mes, pruebo la primera revisión del 15 de febrero: buena, vamos a la tercera semana del mes, 21 de Febrero: buena, con apenas 2 testeos adicionales he reducido el rango a sólo una semana.
Teniendo menos de 40 commits por probar, el git log puede dar ciertas pistas sobre lo que sucedió durante esa semana, así que escogí 7 revisiones sospechosas y comenzé ahora sí, una mini búsqueda binaria, el resultado: 3 testeos fueron suficientes para dar con el guilty commit del 25 de Febrero del 2019, total 13 testos en un rango de 1200+ revisiones, en 3 horas hice lo que pudo tomarme una semana como mínimo.
Como quedó demostrado, se trata de un método muy eficiente y práctico.
