Jesse Vincent (obra) / test-driven-development
¿Por qué el desarrollo guiado por tests funciona mejor con un agente?
Porque el test que falla es lo único que demuestra que el agente entendió la petición.
Lo que conviene recordar
- Un test que falla es una especificación que el agente no puede esquivar hablando.
- Mira fallar el test. Un agente que salta al verde suele haber escrito un test que no puede fallar.
- Los ciclos pequeños son el punto. Los grandes dan la misma falsa confianza que no tener tests.
- Es una skill dentro de una metodología más amplia y funciona mejor junto a writing-plans.
01Qué cambia en la práctica
El problema difícil del código asistido por agentes no es la capacidad, es la verificación. El agente cree que lo consiguió, el diff parece razonable y nadie ha comprobado nada. Un test que falla convierte esa creencia en un hecho mecánico.
También adelanta los malentendidos. Si el agente escribe un test que afirma el comportamiento equivocado, lo descubres en el primer minuto y no después de construir encima.
02Dónde decepciona
Los tests que afirman lo que hace la implementación son peores que no tener tests, porque fijan el defecto. Lee el test, no solo el resultado.
Encaja mal con la exploración. Cuando todavía no sabes cómo es lo correcto, escribir primero la aserción es adivinar con pasos extra.
Instalación y primera ejecución
- Instala superpowers desde obra/superpowers, con licencia MIT.
- Exige ver el test fallar antes de que se escriba implementación.
- Mantén cada ciclo en un comportamiento pequeño, porque un ciclo grande oculta qué falló de verdad.
Preguntas que la gente hace de verdad
- ¿Por qué insistir en ver fallar el test?
- Un test que pasa antes de existir la implementación no prueba nada. Verlo fallar es la comprobación más barata que hay.
- ¿Frena al agente?
- Por cambio sí, y a lo largo de una semana suele ser más rápido, porque elimina el retrabajo de los cambios sin verificar.
- ¿Va aparte del resto de superpowers?
- Es una skill de una metodología mayor. Funciona sola y mejor junto a writing-plans y verification-before-completion.
Fuentes
Versiones legibles por máquina de esta página