Revisión de ‘Test-Driven Development by Example’, de Kent Beck

En esta ocasión revisamos uno de los libros fundamentales sobre una técnica de programación que debería ser indispensable en las costumbres de todo buen programado: el desarrollo dirigido por test o TDD.

A estas alturas, si te consideras un buen programador o al menos aspiras a serlo, deberías conocer el diseño dirigido por test o Test Driven Development (TDD). Se trata de una técnica redescubierta (tal y como aclara el autor quitándole méritos) y popularizada por Kent Beck. Y este libro es precisamente el que se puede considerar como obra oficial de difusión de TDD por parte de su “redescubridor”.

Por si no lo conoces, TDD es una técnica de programación que consiste básicamente en programar en pequeñas y seguras iteraciones siguiendo este ciclo:

  • En primer lugar se comienza expresando una funcionalidad a través de un test sin que haya código que lo satisfaga. Esto dará un fallo de test en “rojo”
  • Se programa el código mínimo que hace pasar el test. Ahora tenemos un test en “verde”.
  • Una vez que tenemos el test en verde, refactorizamos el código para eliminar duplicidades y mejorarlo, pero siempre conservando el semáforo verde.

Repitiendo este ciclo, añadiendo cada vez más funcionalidad expresada con test, logramos tener un código ya testeado, orientado a la funcionalidad, probablemente de mayor calidad y viviremos más felices o al menos con un nivel de ansiedad reducido. Aunque también tiene sus partes negativas: algo más de esfuerzo a corto plazo y cierta sensación de falsa seguridad entre otras cosas, aunque esto daría para un debate.

Si no la conoces, te recomiendo que te formes sobre esta disciplina, bien con este libro que aquí comentamos, o si me lo permites, te recomiendo ‘Diseño Ágil con TDD’ de Carlos Ble, que me parece una gran introducción en castellano. Y cómo no, en Autentia nos tomamos muy en serio el TDD, así que tenemos unas cuantas entradas que tratan sobre el tema en este portal de Adictos al Trabajo: https://www.adictosaltrabajo.com/?s=TDD.

Volviendo a la revisión del libro, podemos considerar que es la obra básica a partir de la cual se expande la idea de TDD. El autor, Kent Beck, a mi juicio emplea una forma muy acertada para transmitir su mensaje: utilizando ejemplos. Si quieres convencer a un programador para que utilice una técnica mejor demuéstrale sobre su terreno: con código y explicaciones de las decisiones sobre ese código.

El libro comienza directamente con un ejemplo de código, que desarrolla a lo largo de 17 capítulos y que conforma la primera de las tres partes del libro. Este ejemplo es uno de los paradigmáticos dentro de la programación de sistemas de gestión: “el dinero”. Parte de una situación real a la que Kent Beck tuvo que enfrentarse en su vida de programador, y que le sirve como excusa para aplicar TDD: a través de pequeños cambios realizados poco a poco, test a test, refactorización a refactorización, va transformando el código hasta llegar a una solución final de altísima calidad, que a buen seguro no hubiera llegado sin emplear TDD.

Este ejemplo inicial está escrito en Java básico y no emplea ningún framework de testing tal y como los conocemos hoy en día. Como ya he hecho notar, se trata de un libro de 2002 así que no había el desarrollo que hay ahora (gracias precisamente a Kent Beck y libros como éste), ni tampoco parece pertinente ensuciar las explicaciones empleando “magia”. Seguro que si no estás familiarizado con TDD, en alguna parte te resultarán evidentes los pasos que da, pero es porque el autor es muy meticuloso con la justificación de cada test, de cada implementación y de cada cambio. Al fin y al cabo de esto va TDD y refactorización: pequeños pasos pero muy seguros.

La segunda parte tiene una extensión más reducida. Una vez ha explicado en la parte primera qué es TDD con el ejemplo del dinero, en esta segunda parte se dedica a desarrollar las necesidades que un framework de testing debería cumplir, y que surgen de toda la implementación anterior. Así, define que debería existir un método de test, otro método para preparar todo el contexto (setup); otro para eliminar el contexto y dejar todo como estaba antes del test (teardown); recogida de resultados. Los test y código de este framework lo implementa en Python (no te asustes si no lo conoces, los ejemplos se hacen muy sencillos) y “casualmente” lo llama xUnit. Imagino que entenderás que los frameworks como JUnit y derivados provienen de estas ideas.

Finalmente la tercera parte está dedicada a los patrones del TDD. Me ha parecido la parte más interesante, sobre todo porque tenía experiencia previa con la técnica y con JUnit, asi que no supusieron grandes sorpresas. Esta parte es más bien un conjunto de consejos y buenas prácticas para llevar a cabo TDD. La mayoría de ellas ya están implícitas en el modo de hacer TDD hoy en día, pero conviene ver su origen y explicación. Se tratan temas como: concentrarse en hacer primero el test, que sean aislados, cómo organizarlos…; otros más curiosos son como afrontar la técnica desde el punto de vista del programador: cuándo descansar, dejar tests fallando al acabar la jornada para forzar a recordar, triangulación; u otros patrones más técnicos y referidos a xUnit como la captura de excepciones, dónde hacer las fixtures o patrones de diseño aplicados a test como el Null Object, Template Method, Factory, Composite. Finalmente, como dentro del ciclo de TDD hay una fase de refactorización, dedica un último capítulo a esta técnica iniciada por Martin Fowler (aquí tienes una entrada con la crítica del libro: Repasando los clásicos: Refactoring, de Martin Fowler).

En general es un libro interesante, pero, como sucede con ‘Refactoring’ de Martin Fowler, hay que encuadrarlo en su época: 2002. En su tiempo fue un libro revolucionario, tal como se ha demostrado la expansión y el reconocimiento general de las ventajas del uso de TDD a día de hoy. Pero en la actualidad, si lo enmarcamos en el estado del arte a finales de 2015, la mayoría de información ya se ha incorporado al quehacer diario de los programadores expertos, y se puede ver plasmada junto con evoluciones posteriores en una extensa bibliografía de TDD.


Cómpralo en Amazon