Desde que me lo presentaron, siempre me ha desagradado el Test Driven Design (TDD), pues me parecía absurdamente burocrático y contra flujo. Afortunadamente, gracias al podcast de Book Overflow, encontré un autor reconocido, John Ousterhout, creador de Tcl/Tk y "A Philosophy of software design", que comparte mi opinón respecto a escribir los test antes de escribir el código y dice que en el TDD no se hace diseño, sino que se depura el software hasta su existencia.
Mi enfoque, que podría llamarse Argumentative Driven Design o ADD es uno en el que el código se desarrolla para mostrar un argumento en favor de una hipótesis, y las pruebas de código se van creando en la medida en que uno necesita inspeccionar y manipular los objetos que dicho código produce.
En palabras práctica, esto quiere decir que los test y su configuración deberían hacerse cuando uno necesita hacer un "print" (para probar/inspeccionar/manipular un estado/elemento del sistema) y no antes, lo cual aumenta la utilidad, no interrumpe el flujo y responde preguntas similares a las de este apartado, respecto a de dónde provienen las pruebas y qué hacer con los resultados exitosos.