Esta es una idea experimental de la cual Kent Beck comenzó a hablar hace un par de meses. La primera vez que escuché al respecto me sonó raro. Ya llevo varias semanas dándole vueltas y me sigue resultado raro pero el hecho de haber estado probándolo me permitió reflexionar sobre mi flujo de trabajo al programar.
Más aún, he estado trabajando en un mini-taller exploratorio de TCR para compartir esta idea y poder destilarla en conjunto con otros practicantes. Voy a aprovechar el Open Space que se realizará en Buenos Aires en el contexto de la semana de la agilidad, los interesados traigan sus notebooks, git y ganas de codear.
Blog de NicoPaez 
Nos vemos el día del evento. Me interesa ver que es lo que sale.
Estuvimos expirimentando con colegas y estos fueron los resultados:
– Necesitas acordar un contrato / diseño para evitar que los desarrollos tomen caminos divergentes. Esto conlleva dificultades en la aplicación de TDD y en la resolución de conflictos (en repos).
– El tiempo de ejecución de pruebas puede ser prohibitivo, en ocasiones queres deshabilitarlos y podes generar un código que potencialmente puede generar breaking changes.
– Fomenta la escritura de pruebas unitarias en lugar de pruebas de aceptación, potencial efecto goldplating.
– Conspira contra la ejecución de pruebas que toman por definición más tiempo (integración, aceptació o e2e).
– Genera código que no se refactorizo. No es grave, debería abordarse en la próxima iteración.