Para los que no conocen la sigla, TDD representa el concepto de Test Driven Development, la metodología de hacer las pruebas de lo que queremos lograr antes del código.

Este es el caso de alguien que estaba demostrando esa metodología ante uno de los escépticos que no creen que sea realmente aplicable. “Funciona muy bien en la teoría pero al momento de la verdad no se puede respetar totalmente”, pensaba. Ese es el caso de Rob Conery, explicando las técnicas de TDD de Brad Wilson.

Lo que él hizo fue, intencionalmente, planear una situación en un sistema medianamente complejo, para luego introducir un nuevo requerimiento que cambiaba todo el diseño. Parece que entonces lo que Wilson hizo fue, en lugar de tirar todo y comenzar de cero, ir adaptando las pruebas gradualmente, ir refactorizándolas hasta que comenzaron a formar “clases”, que luego se movieron del entorno de pruebas al sistema real.

“Un concepto en el que no había pensado nunca” – menciona Conery – “usar el archivo de pruebas como una especie de útero {de dónde nacen las clases}”.

Soy un zorrinito TDD.