El principio en que me voy a basar es el siguiente: cuanto más ligeras las pruebas, más se hacen. No sirve de nada tener un entorno super-complejo que controle las variables en un entorno virtual del copón, porque luego no se usa. Y más cuando están pasando a la historia los laboratorios de testing tradicionales.

Éstos funcionaban de la siguiente manera: cada programador se hacía primero sus pruebas unitarias, luego se pasaba a pruebas funcionales (idealmente hechas por un equipo aparte), y luego se juntaba todo en las pruebas de integración o sistemas (aquí el equipo aparte era una necesidad). Un coñazo tal que se solían saltar las dos primeras fases, y cuando se llegaba a integración, no era raro encontrarse con miles de errores. Y no es en sentido figurado: yo he visto, en una base de datos al efecto que no tenía ni dos años, el error número 10 000. (Sí abuelo sí, tómese su medicina.)

Gracias a la llegada de las metodologías ligeras, como Xtreme Programming, Test Driven Development o FDD, se vio a las claras que este proceso no funcionaba. Y es que estas pruebas unitarias son un coñazo que apenas sirve para nada; los tests de regresión (probar que todo lo anterior sigue funcionando) cuestan sudor y tinta china, y todo lo que no sea automático se hace mal o no se hace. Por eso conviene feriarse un conjunto de pruebas que se ejecuten solas, que funcionan como la red de seguridad en el circo: las cosas seguirán fallando, pero los errores se cazan antes de que sean mortales.

Así que, idealmente, no sólo hay que hacer pruebas en local (que serían equivalentes a las funcionales), sino que es mucho mejor currarse unas pruebas unitarias decentes... y guardarlas. El ser unitarias quiere decir que sólo hay que comprobar aspectos atómicos de una aplicación, no transacciones completas de cabo a rabo. El guardarlas, que el código no se tira; se sube al cvs. Para cada clase importante, conviene probar los métodos que interese, a ser posible en los escenarios chungos: casos límite, parámetros erróneos... Por ejemplo, si quisiera verificar que mi función de división va bien, haría un caso fácil (10/2), uno más complicado (5/7), uno negativo (-7 / 5) y uno con mala hostia (5 / 0 y comprobar que me tira una excepción).

Después, tras cada cambio se ejecutan todas juntas, con lo que te aseguras de que la aplicación sigue funcionando. La motivación de que las pruebas se guardan para otras ocasiones, y se ejecutan fácilmente, hace que lo que antes era un coñazo pase a ser una delicia: te da la seguridad de que tu trabajo funciona.

La librería JUnit para Java te permite hacer los tests de regresión en un momento, y está portada a muchos lenguajes. Cada TestCase contiene varios métodos de prueba, que verifican un aspecto específico de tu aplicación.

Sí, os estoy viendo ahí al fondo: os preguntáis que de dónde vais a sacar el tiempo para escribir estos tests. Muy fácil: del que antes usábais para arreglar los errores una y otra vez. Si a alguien le interesa, puedo dar cifras del tiempo que se gana basadas en mi experiencia, pero de eso que se preocupen los gerentes; lo importante es que la actividad del currito se vuelve mucho más gratificante.