With TDD, you develop code by incrementally adding a test for a new feature, which fails. Then you write the “simplest code” that passes the new test. You add new tests, refactoring as needed, until you have fully covered everything that the new feature should fulfil, as specified by the tests. But: Where do tests come from? When you write a test, you actually have to “guess first” to imagine what objects to create, exercise and test. How do we write the simplest code that passes? A test that fails gives you a debugger context, but then you have to go somewhere else to add some new classes and methods. What use is a green test? Green tests can be used to detect regressions, but otherwise they don't help you much to create new tests or explore the running system. With Example-Driven Development we try to answer these questions.
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.