TDD: Test Driven Development

[1] 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

[2]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. Hacer un test automtico de prueba, ejecutarlo y ver que falla.

2. Hacer el cdigo mnimo imprescindible para que el test que acabamos de escribir
pase.
3. 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.
[1] El proceso de construccin de software se convierte en un ciclo:

1. Aadir un nuevo caso de prueba que recoja algo que nuestro modulo debe realizar
correctamente.

2. Ejecutar los casos de prueba para comprobar que el caso recin aadido falla.

3. Realizar pequeos cambios en la implementacin (en funcin de lo que queremos

que haga nuestra aplicacin).

4. Ejecutar los casos de prueba hasta que todos se vuelven a pasar con xito.

5. Refactorizar el cdigo para mejorar su diseo (eliminar cdigo, duplicado, extraer

mtodos, renombrar identificadores...).

6. Ejecutar los casos de prueba para comprobar que todo sigue funcionando
correctamente.

7. Volver al paso inicial

Ejemplo prctico utilizando TDD:
El ejemplo planteado es realizar la suma y resta de dos nmeros.
Crear un nuevo proyecto

A continuacin nos creamos el caso de pruebas

Luego seleccionamos JUnit4.x porque cuenta con bibliotecas ya declaradas.

Ya tenemos creado nuestro test con JUnit.

Caso de Prueba Suma

Procedemos aplicar el primer caso de prueba de la suma con los pasos de TDD
Hacer un test automtico de prueba, ejecutarlo y ver qu falla.

Errores

Hacer el cdigo mnimo y prescindible para que el test que acabamos de escribir pase.
Arreglamos el cdigo de los errores presentados
Instanciamos la clase Operaciones

Declaramos el mtodo suma en la clase operaciones

Ejecutamos y ya no nos dio error

Pero si aumentamos otro assertEquals con otros valores y ejecutamos no vuelva a dar
error por lo que el mtodo suma () est retornando un numero especifico que es el 3.
A continuacin procedemos arreglar los errores.

Comprobar que el test siga pasando correctamente despus de a ver arreglado el cdigo

Finalmente la prueba realizada de la suma ya no contiene errores por lo tanto la prueba

es correcta.
Segundo caso de prueba Resta
Procedemos aplicar el primer caso de prueba de la resta con los pasos de TDD
Nos creamos el caso de prueba de la resta.
Ejecutamos y visualizamos si tenemos errores
Como se puede observar el primer caso de prueba esta de correcto y el segundo caso de
prueba que es la resta esta con errores.

Procedemos a arreglar los errores en el caso de prueba

Aumentamos el mtodo de la resta

Pero si aumentamos otro assertEquals con otros valores y ejecutamos no vuelva a dar
error por lo que el mtodo resta () est retornando un numero especifico que es el -1.

Corregimos los errores mostrados por el test

Y finalmente ejecutamos y otro caso de prueba est correcto.

CONCLUSIN

Despus de haber finalizado el presente trabajo podemos concluir que el TDD nos ayuda
a visualizar los errores que hay en cada lnea de cdigo de forma unitaria mediante la
separacin de Test por lo cual nos muestra una barra verde si esta correcta o rojo si tiene
errores al momento de ejecutarlo.

BIBLIOGRAFA

[1] C. B. Jurado, Diseo gil con TDD, Creative Commons, 2010.

[2] www.chuidiang.com, TDD: Test Driven Development, [En lnea]. Available:

http://www.chuidiang.com/java/herramientas/test-automaticos/tdd-test-driven-
development.php. [ltimo acceso: 30 Noviembre 2016].

[3] F. Berzal, Test-Driven Development, de Tecnicas utiles en el desarrollo de

software, 2003, pp. 3 - 5.