El desarrollo orientado a pruebas (TDD, test driven development) es una forma de desarrollar basándose en que un cierto algoritmo responda de una forma específica a unos datos específicos. Para explicar mejor esto, voy a explicar primero el enfoque tradicional y luego expongo las mejoras que introduce esta forma.
Enfoque Tradicional
Cuando se pide el desarrollo de un proyecto, lo que se pide es qué hay que hacer sobre el problema planteado. Por ejemplo, un programa de contabilidad, podría consistir, a grosso modo en almacenar los datos contables y ofrecer los informes correspondientes.
En el momento que pasamos a desarrollar la idea, el problema, entramos en el cómo hay que hacerlo. Se desarrolla un modelo en el que se plasma cómo almacenar los datos, cómo presentar los informes y desarrollamos nuestra aplicación basándonos en esas premisas.
Teniendo ya el software desarrollado, el programa ejecutable, pasamos a las pruebas, tras las cuales podemos descubrir fallos y pasar a corregirlos, así hasta que todos los fallos previsibles están controlados.
Si la batería de pruebas es muy completa, se puede tener un programa con un reducido número de fallos, puesto que los modos de uso del mismo habrán sido comprobados.
El problema de este sistema es que, si la previsión o las fases han sido realizadas de forma superficial, es muy posible que ciertos usos hayan escapado de nuestro diseño, es más, es posible que, aún habiendo pedido el cliente un cierto uso, lo hayamos malentendido o no funcione de forma correcta por una decisión de diseño mal orientada.
En ese caso, habría que retroceder hasta el punto del diseño, comprobar de nuevo los requisitos con esta nueva información y continuar hacia adelante. Es un proceso muy lento y tedioso.
Enfoque TDD
Basándonos en el principio YAGNI (you ain't gonna need it?, ¿realmente lo necesitas?), podemos pedir unos casos que cubran la mayor parte de los casos practicables, según los requisitos, de modo que tengamos los datos de entrada y los datos de salida de nuestra aplicación, es decir, no solo saber qué proceso se debe de hacer, sino además, tener un ejemplo palpable de los datos que se deben de poder conseguir, para construir la aplicación con solo y exclusivamente lo que nos pidan.
Teniendo claro qué se debe de hacer, ilustrado con los ejemplos, pasar al cómo es bastante simple, puesto que se trata de realizar un programa que permita hacer el paso de unos datos, de una forma a otra, sin más.
La batería de pruebas está definida, desde antes de comenzar a codificar, y se pueden desarrollar unidades pequeñas que pueden ir probándose para ver que cumplen lo que se pide. Para esto podemos emplear sistemas de pruebas unitarias... los cuales comentaré en otro artículo.
En el ejemplo de las cuentas contables, puede pasar por determinar el uso de las cuentas contables en sí, los datos que se requieren almacenar para los informes y los datos que se deben de introducir por parte del usuario: número de cuenta, concepto, valor, etc.; en lugar de desarrollar un complejo programa que incluya todo referente a la contabilidad en sí.
Este enfoque, en sí fusiona los conceptos de codificación y pruebas, de modo que se hacen de forma conjunta, al disponer de datos para ello. Así mismo, incluye el diseño de las pruebas en el análisis, y se usan como requisito para el diseño, con lo que se puede apreciar que las pruebas, están presentes en todas las etapas de desarrollo y, no hay una etapa separada o específica para ellas, aunque pueda hacerse.
Conclusiones
El desarrollo basado en TDD es muy usado por grupos de desarrollo de metodologías ágiles, está muy probado y combina bien con Xtreme Programming y Scrum, por lo que aconsejo su uso en proyectos de cualquier tamaño.
