Algoritmo de TDD

En esta sección veremos el algoritmo esencial de TDD paso a paso.

La esencia de TDD es sencilla, pero ponerla en práctica correctamente es cuestión de entrenamiento, como tantas otras cosas. El algoritmo TDD solo tiene tres pasos:

• Escribir la especificación del requisito (el ejemplo, el test).

• Implementar el código según dicho ejemplo.

• Re-factorizar para eliminar duplicidad y hacer mejoras.

Escribir el test primero (Ejemplo)

Debemos tener claro cual es el requerimiento, y debemos poder expresarlo en forma de código. Normalmente se debe tener en cuenta si el requerimiento es una tarea o una historia de usuario completa, de ser una historia de usuario usaremos un framework tipo Fit, Fitnesse, Concordion o Cucumber. Esto es, ATDD. De ser una tarea lo haremos con algún framework xUnit. Ahora alguien podría preguntarse ¿Como escribimos un test para un código que todavía no existe? Yo le responderia ¿Acaso no es posible escribir una especificación antes de implementarla?

Implementar el código que hace funcionar el ejemplo

Teniendo el test (ejemplo) escrito, codificamos lo mínimo necesario para que se cumpla, para que el test pase. Típicamente, el mínimo código es el de menor número de caracteres porque mínimo quiere decir el que menos tiempo nos llevó escribirlo. No import si el codigo no es el mejor o muy complejo, el el paso de refactorizacion corregiremos esto o en las siguientes eiteraciones.

En este paso el objetivo es no implementar nada más que lo estrictamente obligatorio para cumplir la especificación. Pero no se trata de hacerlo sin pensar, sino concentrados para ser eficientes. Parece fácil, pero al principio no lo es; veremos que siempre escribimos más código del que se necesita. Si estamos bien concentrados, nos vendrán a la mente dudas sobre el comportamiento del SUT (Subject Under Test) ante distintas entradas, es decir, los distintos flujos condicionales que pueden entrar en juego; el resto de especificaciones de este bloque de funcionalidad. Estaremos tentados de escribir el código que los gestiona sobre la marcha y, en ese momento, solo la atención nos ayudara a contener el impulso y a anotar las preguntas que nos han surgido en un lugar al margen para convertirlas en especificaciones que retomaremos después, en iteraciones consecutivas.

Refactorizar

Re-factorizar no significa reescribir el código; Según Martin Fowler, refactorizar es modificar el diseño sin alterar su comportamiento. A ser posible, sin alterar su API pública. En este tercer paso del algoritmo TDD, rastreamos el código (también el del test) en busca de líneas duplicadas y las eliminamos refactorizando.

Además, revisamos que el código cumpla con ciertos principios de diseño (como S.O.L.I.D) y refactorizamos para que así sea. Siempre que llego al paso de refactorizar, y elimino la duplicidad, me planteo si el método en cuestión y su clase cumplen el Principio de una ´Única Responsabilidad11 y demás principios.

El propio Martin Fowler escribió uno de los libros más grandes de la literatura técnica moderna en el que se describen las refactorizaciones más comunes. Cada una de ellas es como una receta de cocina. Dadas unas precondiciones, se aplican unos determinados cambios que mejoran el diseño del software mientras que su comportamiento sigue siendo el mismo.

Mejora es una palabra ciertamente subjetiva, por lo que empleamos la métrica del código duplicado como parámetro de calidad. Si no existe código duplicado, entonces hemos conseguido uno de más calidad que el que presentaba duplicidad. También poder realizar un código menos repetible, más claro y legible.

Cualquier cambio en los adentros del código, que mantenga su API pública, es una refactorización. Cada una de estas debe ser en pasos pequeños. Se hace un cambio, se ejecutan todos los tests y, si todo sigue funcionando, se hace otro pequeño cambio. Cuando refactorizamos, pensamos en global, contemplamos la perspectiva general, pero actuamos en local. Es el momento de detectar malos olores y eliminarlos. El verbo refactorizar no existe como tal en la Real Academia Española, pero, tras discutirlo en la red, nos resulta la mejor traducción del termino refactoring.

La tarea de refactorización debe hacerse siempre después de los otros dos pasos anteriores de otra manera no podemos asegurar que estamos haciendo TDD.