TDD son las siglas de Test Driver Development un proceso de desarrollo de software que se basa en la idea de desarrollar pruebas, codificar y refactorizar el codigo construido.

El procedimiento que hay que seguir para desarrollar aplicando TDD, Test Driver Development, es muy sencillo, a continuacion veremos como usar esta metodologia, o procedimiento de desarrollo, muy comun entre los seguidores de las metodologias agiles.

TDD se basa en la idea de realizar pruebas unitarias para el codigo que debemos construir. A diferencia del procedimiento que usamos habitualmente, construir el codigo y despues realizar las pruebas unitarias, TDD establece que primero hay que realizar una prueba y a continuación desarrollar el codigo que la resuelve.

Obviamente el metodo TDD no acaba aqui, ya que ademas añade el code refactoring, re-estructuracion del codigo implementado, un factor importante que no debemos olvidar.

Como afrontar TDD

El metodo a seguir es sencillo. Consiste en elegir uno de los requisitos a implementar, buscar un primer ejemplo sencillo del requisito, crear una prueba unitaria, ejecutar la prueba, implementar el codigo minimo para superar la prueba y ejecutar de nuevo la prueba para ver que se supera.

Obviamente la gracia de ejecutar la prueba despues de crearla es ver que esta falla y que sera necesario hacer algo en el codigo para que esta pase.

A continuacion solo es necesario volver a aplicar el proceso descrito anteriormente hasta haber resuelto la funcionalidad o funcionalidades que se debian implementar.

A demas una vez pasada la prueba es necesario revisar el codigo, por si requiere refactoring. Si es el caso, se revisara, corregira y se ejecutaran las pruebas unitarias, de nuevo.

Es importante tener presente que solo se crea un test por iteracion y solo se implementa el codigo minimo necesario para resolver ese caso. No es bueno "emocionarse" implementando y desarrollar mas de lo necesario para resolver el caso de prueba. Si nos vamos por las ramas desarrollando mas casos perderemos una gran parte de la eficacia de este metodo.

 

Ciclo de desarrollo de TDD

tdd-cycle

Elegir un requisito a desarrollar

Crear la prueba o test

Ejecutar los tests: falla (ROJO)

Crear codigo especifico para resolver el test

Ejecutar de nuevo los tests: pasa (VERDE)

Refactorizar el codigo

Ejecutar los tests: pasa (VERDE)

 

Ventajas de usar TDD

La pregunta habitual cuando alguien te habla sobre TDD es ¿Porque es mejor hacer las pruebas antes que el codigo?

Para responder a esta pregunta tenemos que pensar en la forma que se aplica TDD. Por un lado si se implementa y después se realizan las pruebas estas suelen estar condicionadas a lo implementado, con lo que es facil obviar pruebas o olvidar algunos casos de test.

Por otro lado al realizar primero las pruebas se realiza un ejercicio previo de analisis, en profundidad, de los requisitos y de los diversos escenarios. Eliminando la mayor parte de variabilidad y encontrado aquellos aspectos mas importantes o no contemplados en los requisitos.

El hecho que a demas solo se implemente el codigo necesario para resolver un caso de prueba concreto, pasar la prueba, hace que el codigo creado sea el minimo necesario, reduciendo redundancia y los tipicos bloques de codigo de "por si a caso" que habitualmente se convierten en codigo muerto.

Obviamente la obtención de un buen resultado aplicando TDD depende de realizar un conjunto de pruebas unitarias que cubran todos los casos descritos en los requisitos. Es cierto que habra que trabajar la tecnica para realizar buenos test, siendo aqui donde reside una de las mayores dificultades de este metodo.

No obstante hay que remarcar que TDD no solo se basa en las pruebas. Una correcta aplicación de la etapa de refactoring hace que nuestro codigo sea mas legible, optimo y facil de mantener, factores que no siempre priman en nuestros proyectos. Hay que aplicar concienzudamente el paso de refactor, que es el que aportara un valor extra a nuestro codigo.

Tambien que destacar que dado que el codigo evoluciona con el paso del tiempo el refactoring debe aplicarse, siempre que sea necesario, tanto al codigo implementado como a las pruebas unitarias, con el fin de mantenerlas actualizadas, añadiendo nuevos casos, cuando sea necesario, o completandolas al detectar fallos en el codigo.

Os espero en el proximo post sobre TDD donde veremos algunos ejemplo que nos ayudaran a entenderlo mejor.

PD: Os animo a comentar y plantear vuestras dudas en los comentarios del post.

← Back to blog