Creo que he llegado tarde a la discusión sobre TDD, pero tengo que decir en un par de proyectos en los que he utilizado esta metodología, uno ha sido una pérdida de tiempo y en otro la salvación, y además curiosamente, la pérdida de tiempo ha sido en el segundo en vez de en el primero.
Las conclusiones que he sacado son que para utilizar TDD, tienes que tener el alcance de la aplicación bien definido y unos requisitos MUY marcados, porque como te cambie el alcance en mitad del proyecto, aunque sea mínimamente, tienes que volver a programar todas las pruebas, y esto supone una pérdida de tiempo enorme.
Creo que con TDD ocurre algo parecido al desarrollo clásico de proyectos (UML, casos de uso, plan de pruebas, etc). Es una pérdida de tiempo invertir mucho esfuerzo en análisis cuando no se tiene el alcance bien definido, porque a la mínima que se produzca un cambio ya nos habremos cargado la mayor parte del análisis, habrá que rediseñar las pruebas, etc.
Es por eso, que para proyectos personales, en los que en la mayoría de ocasiones realizamos cambios a menudo, creo que la mejor metodología es realizar pequeños bocetos en papel para definir lo que queremos, un mínimo esquema de la arquitectura, e ir realizando pruebas a la vez que vamos implementando la aplicación.
Hay que tener en cuenta que, cuando programamos para uno mismo siempre queremos lo mejor, y buscamos lo más innovador y más susceptible a cambios o ampliaciones. Cuando programas para un cliente sólo buscas cumplir el contrato (requisitos) y ahí si tiene cabida el TDD.