La premisa era que Brad necesitaba crear un sistema de facturación por suscripción que disparara las facturas periódicas y también actualizara el registro del Cliente, usando C # y xUnit.net (marco de prueba de Brad que creó con Jim Newkirk). Para muchos, esto suena simple. Para aquellos que han implementado tal cosa, es todo lo contrario.
Lo que realmente disfruté de este episodio es que empujé a Brad lo suficiente como para eliminar la "carátula de demostración": le di una bola curva durante unos 30 minutos y dije "Oh, sí ... mencioné que también hacemos X ? - Y tuvo que adaptarse.
Cuando tienes un montón de pruebas que suponen una cosa, entonces tienes que cambiar a otra: es un dolor de cabeza. Pero Brad lo manejó increíblemente bien: aprovechó la oportunidad para impulsar más estructura en su proceso de prueba y luego, una por una, "hizo la transición" de sus viejas pruebas al nuevo enfoque.
Trabajamos toda la hora dentro de un único archivo de código, y nunca había visto a nadie hacer eso antes. Claro, he creado una clase allí dentro del código, pero ver a Brad girar clase tras clase, luego renombrar, luego eliminar, luego reestructurar completamente sus pruebas ... fue muy, muy interesante.
Siempre dicen que TDD es un "proceso de diseño", sin embargo, nunca lo he visto utilizado de una manera realmente "de diseño", como un pintor podría arrojar color tras color en un lienzo hasta que se vea / sienta bien. Y así es exactamente como se sentía al verlo.
Unos 15 minutos en Brad menciona que "dejo una clase en el archivo de prueba hasta que esté lista para salir a bolsa", lo que significa que tiene suficientes pruebas para justificar sus decisiones de diseño. Un concepto en el que nunca había pensado antes, algo así como usar el archivo de prueba como un "útero".
Él "sintió" su camino a través de la creación del sistema de facturación, hablando consigo mismo todo el tiempo y creando algo bastante interesante y muy cercano a lo que terminamos después de casi 3 años de estar en vivo.