A mí siempre me ha gustado programar de poco en poco, haciendo un trozo de código que se puede arrancar y ver, luego añadir otro trozo que también se puede arrancar y ver y así sucesivamente. Nunca me ha gustado liarme a escribir código durante varios días, sin probar nada, y luego arrancarlo y pasarme otros varios días haciéndolo funcionar. No sé qué es mejor, pero desde luego, me gusta más lo primero, es más entretenido. Tiene la pega de que "pierdes", sobre todo en proyectos grandes, mucho tiempo compilando. Haces algo en uno o dos días, compilas y pruebas, repites, y repites.
Por todo esto, TDD es una metodología que me gustó desde que la descubrí. Básicamente dice que hay que hacer lo que yo hago, implementar un poco y probar. Sin embargo, TDD es por supuesto más estricto y organizado. Antes de programar, debes hacer unos test para ver que fallan. Luego debes implementar tu código para que no falle y finalmente debes refactorizar para que tu código si adapte bien al resto del código y viceversa.
Así que he tratado de adaptar mi forma de trabajo a TDD. Pero me encuentro con un problema con la refactorización. No es lo mismo ir haciendo código y refactorizar según vas viendo código chapucero, que esperar a tener algo funcionando y luego refactorizar para adaptar tu código o el código ya hecho el uno al otro. Mi principial problema es la memoria de mosquito. Una vez tengo mi código, ya no me acuerdo con detalle de cómo estaba hecho el anterior, y no sé qué tengo que refactorizar para que se adapten el uno al otro. No me queda más remedio que dar un repaso a lo ya hecho para ver qué juntar.
Supongo que a la larga incluso es mejor, ya que el repaso del código para mejorarlo tiene que ser bueno, pero no deja de ser un poquito pesado.