Gracias a Dios por las pruebas de regresión. Ahí estaba yo, a principios de esta semana, sintiéndome muy bien por un nuevo código que había escrito y (pensé) depurado. Estoy en el proceso de mejorar las funciones de OpenVOS POSIX que convierten los valores binarios de tiempo a la estructura de tiempo desglosada ("struct tm" para ustedes los expertos en C). En 1998, cuando originalmente modifiqué estas rutinas para que funcionaran en el entorno POSIX, tomé un atajo y llamé a las subrutinas subyacentes del núcleo VOS. Este enfoque era rápido y simple pero significaba que nuestros tiempos de ejecución POSIX no podían manejar fechas entre 1970 y 1980, porque VOS no maneja esas fechas. Últimamente, he estado portando varios paquetes nuevos de código abierto a OpenVOS 17.0. Descubrí que estábamos fallando un montón de pruebas porque no podíamos manejar este rango de fechas. Así que me puse a la tarea de modificar el código para manejar todas las fechas tanto en la época de la VOS como en la de UNIX (1970 a 2048). Sabía que esta tarea sería propensa a errores, y estaba decidido a encontrar una manera de eliminar todos los errores del código. Una de las cosas buenas de trabajar con fechas es que el conjunto es finito. Además, como las computadoras modernas son bastante rápidas, no es tan difícil hacerlas funcionar con todas las combinaciones posibles y ver qué pasa. Quería asegurarme de probar el área del código que manejaba 1970 y 1971, por razones que no voy a entrar aquí. Así que escribí una prueba que se convirtió 2 veces al día, a partir del 1 de enero de 1970 y hasta el presente. Utilizó sólo una fracción de segundo del tiempo de la CPU. Por supuesto, encontré un error de poste en mi código. Corregí el error y luego la prueba pasó. Me sentía muy bien con este proceso, y mis auditores aprobaron los cambios, y pensé que ya estaba listo. Entonces, un colega mío ejecutó el test de regresión sobre mis cambios. Hacemos esto después de cada cambio en los compiladores y sus tiempos de ejecución, sólo para asegurarnos de no romper nada accidentalmente. Desafortunadamente para mí, varios de los tests de regresión fallaron. Cuando descubrí por qué mis pruebas no lo habían detectado, a pesar de la aparente minuciosidad de la prueba, descubrí que los problemas no surgieron hasta 2038. Aunque había añadido la década de 1970 a 1980 a las rutinas de tiempo, había cortado la década de 2038 a 2048. Por supuesto, cuando volví y probé cada día en el rango, demostré que mi prueba habría detectado el problema, si tan sólo lo hubiera pedido.
¿Cuál es la lección aquí? Supongo que la más obvia es que si puedes probar todas las combinaciones, entonces asegúrate de probar todas las combinaciones. Tal vez una lección más importante es tomarse el tiempo para construir un conjunto de pruebas de regresión. Vale la pena el tiempo y el esfuerzo. Pueden reducir el costo y acortar el tiempo de encontrar y arreglar problemas a medida que mejoras tu código. No tienes que evitar muchos problemas reportados por los clientes para justificar el costo de crear un conjunto de pruebas de regresión. Estimo que el costo de arreglar un problema de software aumenta en un orden de magnitud con cada fase adicional del proceso. Como hay al menos 4 fases en cualquier proceso (diseño, código, prueba, despliegue), las cosas se encarecen bastante rápido.
Empresa