Elaborado por:

Olger Condori orconen

Curso: Ingeniera de Software II. Tema: TDD en java. Profesor: Ing. Mario Aquino Cruz.

TDD: Test Driven Development

Cuando hacemos una aplicacin, es muy importante probar el cdigo. Una solucin es ejecutar muchas veces la aplicacin cuando est acabada, pero especialmente mientras la estamos desarrollando, y probar mucho, muchas veces, una y otra vez. Otra solucin ms eficiente (y menos aburrida), consiste en hacer test automticos de prueba, que se ejecuten automticamente cada vez que compilamos. De esta forma, sin que nos cause ningn trastorno, nuestra aplicacin se estar probando sola una y otra vez. Y la mejor forma de asegurarnos que escribimos estos test automticos y que la mayor parte de nuestro cdigo se prueba, consiste en hacer primero los test. NO hacemos cdigo y luego el test que lo prueba, sino que primero pensamos una cosa concreta que tiene que hacer nuestra aplicacin, luego hacemos el test que prueba que nuestra aplicacin hace eso y despus (y slo despus de hacer el test), hacemos el cdigo necesario para que ese test pase correctamente. Y siguiendo esta filosofa, nace precisamente TDD (Test Driven Development). Una metodologa en la que primero se hace un test y luego el cdigo necesario para que el test pase. No se hace nada de cdigo si no falla algn test, por lo que primero debemos hacer el test que falle.

Los tres pasos de TDD.

En TDD deben seguirse estos tres pasos y en este orden: 1. 2. 3. Hacer un test automtico de prueba, ejecutarlo y ver que falla. Hacer el cdigo mnimo imprescindible para que el test que acabamos de escribir pase. Arreglar el cdigo, sobre todo, para evitar cosas duplicadas en el mismo. Comprobar que los test sigue pasando correctamente despus de haber arreglado el cdigo.

Estos tres pasos deben repetirse una y otra vez hasta que la aplicacin est terminada. Vamos a ver con un poco de detalle qu implica cada uno de estos tres pasos. Por supuesto, con un ejemplo tonto. Supongamos que queremos una clase Matematicas con un mtodo esttico que hace una suma y nos devuelve el resultado.

1. Primero creamos un proyecto llamado TDD_Suma.

Luego importamos la librera JUnit 4.

2. Luego creamos nuestro JUnit Test Case llamado testSuma.

3. Hacer el test automtico. Luego creamos un mtodo llamado TetsSuma.

Lo primero que deberamos ver es que el test ni siquiera compila. No existe la clase Matematicas y, por supuesto, no tiene el mtodo suma(). Y esta es la primera ventaja de TDD. Nos ha obligado a pensar exactamente qu queremos que haga nuestra aplicacin desde fuera de ella. Necesitamos una clase que tenga un mtodo suma() con dos parmetros que nos devuelva el resultado de la suma. Este caso es muy trivial, pero cualquiera que haya programado un poco en serio, sabr que muchas veces no sabemos exactamente qu clases hacer o qu mtodos ponerle exactamente. Es ms, muchas veces perdemos el tiempo haciendo mtodos que pensamos que luego sern tiles, cuando la cruda realidad es que muchas veces no se van a usar nunca. Con TDD slo hacemos lo que realmente necesitamos en ese momento.

Luego ejecutamos y nos devuelve el siguiente error.

4. Hacer el cdigo mnimo imprescindible para que el test pase. Para que el test pase, lo primero que hay que crear es la clase Matematicas y ponerle el mtodo suma(), que debe devolver algo, cualquier entero, para que al menos compile.

Luego compilamos. Ya compila el test y la clase, pero si ejecutamos el test, fallar, ya que el mtodo devuelve 0 y no 5.

Corregimos la clase de la forma ms inmediata posible para que pase el test. Y lo ms inmediato es hacer que devuelva 5.

Nuevamente compilamos. Ya est. Todo funciona como debe. Obviamente, poner return 5 no es la solucin correcta y en un caso real tan simple, pondramos directamente return a+b. Pero de momento, djame ponerlo as para poder explicar el siguiente pas.

5. Rehacer el cdigo. El tercer paso es arreglar el cdigo. Debemos arreglar sobre todo duplicidades. A veces, estas duplicidades son evidentes (por ejemplo, cdigo repetido), pero otras, como en este caso, no son tan evidentes. Qu hay repetido en este cdigo? Aparentemente nada, pero pensemos un poco. De dnde sale ese 5? Lo hemos puesto porque mentalmente hemos hecho la suma 2+3 y sabemos que ese es el resultado. Si no lo hubiramos hecho, habramos puesto return 2+3. Y esa es precisamente la duplicidad. El nmero 2 est repetido en el cdigo: en nuestra clase de test y en nuestra clase Matematicas. Lo mismo con el 3. Podemos eliminar esa duplicidad implementando la solucin obvia:

Finalmente terminamos y para comprobar que est bien compilamos, dando el siguiente resultado.

Bueno, este caso es demasiado simple y en un caso real no haramos tantos pasos para algo tan evidente.