Capítulo 31: Green Bar Patterns - TDD By Example

El objetivo del ciclo «red/green/refactor» es, principalmente, estar el menor tiempo posible en «red». Hay que salir de ese estado lo más rápido posible y se puede salir de ese estado realmente rápido aunque a veces el resultado sea un paso transitorio para hacer una refactorización posterior.

Los siguientes patrones se utilizan para salir de estado «red».

Fake it (‘Til You Make It)

La primera implementación cuando se tiene una prueba con error es devolver una constante. De esta manera se sale del estado «red», entramos en «green» y pasamos a «refactor» de manera que gradualmente se transforma la constante en un uso de variables.

En la implementación de xUnit se puede observar que en uno de los primeros pasos se devuelve la cadena como una constante:

Y se va transformando con el uso de variables:

Y más tarde:

Hay dos efectos derivados de estar en «green»:

• Psicológico: en el estado «green» tenemos la seguridad de que todo se ejecuta correctamente. Se puede refactorizar con confianza.
• Control del alcance: empezar con un ejemplo concreto e ir generalizando es más fácil que tratar de abarcar todos los cambios de una sola vez.

«Fake It» no vulnera la regla de no escribir código que no es necesario porque en los pasos de refactorización se elimina la duplicación de datos entre la prueba y el código. Por ejemplo:

Como se puede observar la duplicación se encuentra entre la prueba y el código. Se puede evitar cambiando el método «yesterday» para que no esté duplicado.

Se ha cambiado pero sigue habiendo duplicación. Sin embargo, desde que  «MyDate('1.3.02')» es el propio objeto «this» podemos eliminar la duplicación.

No todo el mundo está convencido de algo tan sofisticado por lo que puede utilizar «Triangulate» hasta que uno se canse y empiece a utilizar «Fake It» o incluso «Obvious Implementation».

Triangulate

Se puede hacer las abstracciones de las pruebas de una manera más conservadora si sólo se abstrae cuando se tienen dos o más ejemplos.

Por ejemplo, si queremos hacer una prueba para implementar una función la cual queremos que sume dos números tendríamos:

Si estamos triangulando entonces tendríamos que escribir otra prueba.

Con esta segunda prueba ya surge la necesidad de abstraer la solución y utilizar las variables.

La triangulación es una herramienta útil en aquellos casos en los que no se está seguro sobre la correcta abstracción. En cualquier otro caso se recomienda usar «Fake It» u «Obvious Implementation».

Obvious Implementation

Tanto «Fake It» como «Triangulation» se centran en el desarrollo en pequeños pasos. Si la implementación es tan sencilla que no necesita de pequeños pasos para realizarse entonces se puede implementar directamente. Esto es la «Obvious implementation».

Es posible que hacer un código que funcione y que a la par sea un código limpio sea demasiado para hacerlo a la vez. Si esto empieza a suceder habría que regresar para solventar la parte de que funcione y, más tarde, el código limpio.

One to Many

Cuando tenemos que implementar una operación que trabaje con colecciones de objetos la estrategia a seguir es implementar primero la operación para una objeto y después hacer que esta funcione con colecciones.

Por ejemplo, supongamos que tenemos que escribir una función que sume un array de números. Primero empezamos sumando un número.

El objetivo es sumar una colección de número así que añadimos un nuevo parámetro a la función para que admita una array de valores.

Este paso es un ejemplo de cómo aislar el cambio. Una vez añadido el parámetro en la prueba se puede cambiar la implementación sin que afecte a la ejecución de la prueba. Ahora podemos cambiar la implementación para  usar el array.

Ahora podemos eliminar el parámetro «value» que inicialmente definimos.