El lado oscuro de las pruebas.

Saludos.

De un tiempo a esta parte, con la aparición de metodologías extremas, diseño guiado a pruebas y herramientas tipo jUnit, se han puesto de moda las pruebas. Parece que, cuantas más pruebas tenga un programa, mejor. Pero tener un número elevado de pruebas tiene un lado oscuro que puede traer problemas.

Si las pruebas son pequeñas y simples, las podemos escribir en un momento, pero si aumenta su tamaño (y no podemos dividirlas en pruebas más pequeñas) se hacen difíciles de escribir. Además a más código más errores, por lo que tenemos que perder tiempo depurándolas. Si nuestra prueba tiene mucho código o es compleja, ¿cómo podemos asegurarnos de que nuestra prueba funciona adecuadamente? ¿Tenemos que escribir una prueba para probar la prueba?.

Esto es malo, pero podemos encontrar algo todavía peor. Supongamos que tenemos una clase y 10 pruebas que dependen de dicha clase. Con el uso se ha descubierto que hay una manera mejor de crear objetos de esa clase cambiando los constructores. Ese cambio supondría, no solo cambiar en el código donde se crean objetos de esa clase (muy pocos si programamos bien 8) ) sino tener que modificar esas 10 pruebas.
Además habría que repasarlas para comprobar que sigan teniendo sentido después de la modificación y, probablemente, escribir pruebas nuevas.

En este caso el problema no es muy grande, pero si cambiamos (o refactorizamos) mucho código, el número de casos de casos de prueba a modificar aumenta, con el consiguiente gasto de tiempo para modificarlas. Recordemos que las pruebas no son parte del sistema (no se la entregamos al cliente ni, probablemente, el cliente aprecie su utilidad), por lo que no debemos gastar demasiado tiempo con ellas.

Esto nos puede llevar a dos decisiones igual de malas: o bien no modificar el código para seguir aprovechando las pruebas que ya tenemos, o, lo más común, modificar el código y tener un conjunto de pruebas obsoletas e inservibles.

Este problema no es exclusivo en las pruebas de código "tipo jUnit". También sucede lo mismo trabajando, por ejemplo, con robots de prueba que capturan pulsaciones de teclado o ratón y luego las reproducen. En este caso, un mínimo cambio en la interfaz gráfica puede obligar a modificar (o a volver a grabar) un buen número de pruebas.

En resumen. Cuanto más pruebas, por ejemplo pruebas de código, tengamos, más atados estamos a dicho código y menos ganas de cambiar nada tenemos..

¿Cuál puede ser una la solución?. Creo que una buena alternativa sería generar las pruebas de manera automática. Si tuviéramos un programa que permitiera apretar un botón y obtener un buen conjunto de pruebas (e incluso ejecutarlas), no nos preocuparíamos a lo hora de cambiar el código. En cada cambio descartaríamos todas las pruebas obsoletas y generaríamos pruebas nuevas fácilmente.

Esto es muy fácil de decir pero muy difícil de poner en práctica (por no decir imposible). Espero seguir hablando de esto en futuras entradas.