En el contexto de mi investigación sobre TDD decidí a arrancar desde cero a pesar de llevar ya varios años aplicando y enseñando TDD. La técnica Test-Driven Development (TDD) fue «creada» por Kent Beck durante los 90. Y pongo creada entre comillas porque el mismo Beck se define asimismo como «redescubridor» de TDD. Al margen de este acto de humildad, la realidad es que si bien Beck había leído sobre la idea de escribir el código de prueba antes que código funcional, TDD es una técnica que implica mucho más que esa idea.

Sinceramente desconozco cual sea primera mención formal a Test-Driven Development, pero la primera que yo conozco data de la primera edición del libro Extreme Programming Explained escrito por Beck y publicado en 1999. En dicho libro Beck no habla exactamente de Test-Driven Development como técnica sino que simplemente habla de escribir los tests antes de la funcionalidad y hace referencia a esto como estrategia Test-First.

Recién en su libro Test-Driven Development by Example publicado en 2003, Beck entra en los detalles de la técnica TDD. Hace ya años que no recomiendo este libro como puerta de entrada a TDD, porque personalmente me costó mucho hacer el salto de lo que propone el libro «al mundo real». Tengamos presente que los ejemplos del libro (que básicamente son 2 ejemplos tratados con bastante profundidad) están centrados en lo que podríamos denominar la capa de dominio y no lidian con nada de la infraestructura. Esto está muy bien para entender las ideas centrales de la técnica pero resulta insuficiente para poder aplicarla en «contextos industriales». Sin embargo, a partir de mi trabajo de maestría volví a leer el libro y esta relectura me llevó a revalorizarlo. Me resulta interesante cómo algunas cuestiones que descubrí practicando TDD están mencionadas en el libro, pero que en mi primera lectura yo pasé completamente por alto. Más aún, tengo la sensación de que algunas de esas cuestiones son reiteradamente subestimadas por practicantes y «evangelizadores» de TDD. Una de esas cuestiones es la naturaleza iterativa de TDD. Esta naturaleza iterativa, que también es parte central de Agile y DevOps, implica que tenemos que estar dispuestos a avanzar en una dirección con intención exploratoria aún cuando eso pueda implicar volver atrás. Llevado al código esto puede implicar escribir código (funcional o de prueba) sabiendo que en breve lo eliminaremos. Y cuando digo en breve no es dentro de 3 semanas o 3 meses, sino tal vez dentro de 15 minutos.

Son muy pocos los libros que he vuelto a leer de punta a punta. Muchas veces leo un libro de punta a punta cuando lo leo por primera vez y luego vuelvo a leer (generalmente a modo de consulta) algún capítulo en particular. Pero esta vez decidí volver a leer Test-Driven Development by Example de punta a punta otra vez y creo que ha sido una gran inversión pues me ha permitido reflexionar, cuestionarme y entender más profundamente algunas cuestiones.

Mientras escribo estas líneas reflexiono y me convenzo de que si bien yo estoy empezando mi investigación sobre TDD leyendo Test-Driven Development by Example, no es lo que yo recomendaría a un practicante, o sea, a alguien quien aprender TDD para aplicarlo en desarrollo de software. De hecho, la cuestión de por dónde empezar a aprender TDD es una de las cuestiones intento abordar en mi trabajo de investigación.