TDD (Test Driven Development)
- Escribimos una prueba que recoja nuestros requisitos.
- Ejecutamos la prueba. Esta debe fallar, en caso contrario es que no estamos desarrollándola bien, por lo tanto no es válida.
- Se escribe la mínima cantidad de código necesaria para que el test pase.
- Se vuelve a ejecutar la prueba, esta debe correr exitosamente.
- Se recomienda refactorizar el código escrito, ya que cualquier cambio que hagamos vamos a estar seguros que nuestro código va funcionar si los tests son favorables.
- Repetimos el punto uno para el siguiente requisito.
- El cliente escribe su historia de usuario.
- Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible.
- Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.
- Se comprueba que esta prueba falla.
- Se escribe el código que hace pasar la prueba.
- Se ejecutan todas las pruebas automatizadas.
- Se refactoriza y se limpia el código.
- Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando.
- Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.
public void testSuma() {
assertEquals(8, Calculadora.suma(3,5));
}Esto supone un cambio de mentalidad, primero escribo cómo debe funcionar mi programa y después, una vez lo tengo claro, paso a codificarlo.
Al escribir el test se está diseñando cómo va a funcionar el software, pienso que para cubrir la prueba voy a necesitar una clase Calculadora con una función que se llame Suma y que tenga dos parámetros.
Esta clase todavía no existe pero cuando la cree, ya sé cómo va a funcionar. Este caso es muy trivial, pero muchas veces no sabemos exactamente qué clases hacer o qué métodos ponerle exactamente.
Es más, a menudo perdemos el tiempo haciendo métodos y clases que pensamos que luego serán útiles, cuando la cruda realidad es que muchas veces no se van a usar nunca. Con TDD sólo hacemos lo que realmente necesitamos en ese momento.
Realmente es la forma natural de pensar, primero pensamos en “¿Qué?” queremos hacer y después pasamos al “¿Cómo?”, la diferencia es que con TDD el test ya queda escrito y se ejecutará cada vez que compilamos nuestro programa.
Por supuesto, si intentamos pasar este test nos dará un error, porque la clase Calculadora aún no existe.
Ahora pasamos a escribir el código de la clase, es fácil porque ya sabemos exactamente cómo se va a comportar:
public class Calculadora {
public static int suma (int a, int b) {
int c = a + b;
return c;
}
}Ahora ejecutamos la prueba y ya tenemos el código funcionado con la prueba pasada.
Una vez todo esté funcionando, pasamos a refactorizar y a eliminar código duplicado, este ejemplo es extremadamente sencillo, y en un caso real no haríamos tantos pasos para algo tan evidente, pero el código mejorado podría ser por ejemplo:
public class Calculadora {
public static int suma (int a, int b) {
return a+b;
}
}En ejemplos más complejos, según vayamos escribiendo más test, deberíamos buscar código duplicado y agruparlo en funciones o utilizar la herencia o el polimorfismo.
Es importante pasar todos los test después de refactorizar por si nos hemos cargado algo.
Ahora deberíamos volver al punto 3 con tests más complicados y repetir el proceso, por ejemplo, podíamos pasar a que el algoritmo admita sumar números decimales, etc.
Esta forma de trabajar es también muy buena para entender el código. Sabemos que la calidad del diseño de un software está también relacionada con el conocimiento del equipo de desarrollo en relación al dominio en cuestión. En este sentido, las pruebas son una muy buena forma de entender el código y su funcionamiento, muchas veces incluso mejor que la documentación.
Es una metodología de desarrollo ágil ideal para proyectos de tamaño medio desarrollados con lenguajes compilados, como páginas web desarrolladas en Action Script o aplicaciones móviles.
Veamos un poco más sobre esta metodología:
