¿Qué hace Desarrollo Guiado por Pruebas (TDD)?
Escribe primero la prueba que falla. Obsérvala fallar. Escribe el código mínimo para pasarla. Refactoriza. Una prueba que pasa inmediatamente no demuestra nada — nunca viste que detectara un error.
Ley de hierro: Nada de código de producción sin una prueba que falle primero. Si escribiste código antes de la prueba, bórralo y empieza de nuevo. "Conservar como referencia" es probar después disfrazado — borrar significa borrar.
Cuándo usar
- Al implementar cualquier nueva funcionalidad o comportamiento
- Al corregir un error (repruébalo con una prueba primero — el Patrón Pruébalo)
- Al refactorizar o cambiar comportamiento existente
- Se activa con "tdd", "test-driven", "rojo verde refactor", "red green refactor"
No para: generar pruebas para código ya escrito (usa test-generation);
prototipos desechables o configuración pura (impleméntalo directamente).
Excepciones (confirma con el usuario): prototipos desechables, código generado, cambios de configuración pura sin impacto en el comportamiento.
Pasos
0. Descubre el stack primero
El ciclo es universal; los comandos no lo son. Antes de la primera prueba, averigua cómo
prueba este repositorio: lee package.json / pyproject.toml / Cargo.toml /
pom.xml / go.mod, busca ./gradlew, Makefile, flujos de CI y
convenciones de nombres de archivos de prueba existentes. Nunca asumas npm test — usa el comando
propio del repositorio para cada verificación ROJA, VERDE y final.
1. ROJO — escribe una prueba que falle
Un comportamiento, una prueba, un corte vertical (bala trazadora que responde a lo que te enseñó el último ciclo). Escribe la prueba que desearías que existiera — describe la API deseada, no la implementación. Nómbrala como una especificación ("rechaza email vacío", no "prueba1").
Acuerda la unión (interfaz pública bajo prueba) antes de escribir. Ninguna prueba sobre una unión no confirmada — acordar uniones por adelantado concentra el esfuerzo de prueba en rutas críticas en lugar de en cada caso extremo. Usa código real en lugar de simulaciones; si debes duplicar una dependencia, usa la simulación más simple que funcione (Real > Fake > Stub > Mock — consulta references/test-strategy.md). Los mocks aíslan fronteras, no la cosa que se está probando.
2. Verifica ROJO — obsérvala fallar
Ejecuta el comando de prueba enfocado. Confirma:
- Falla (no da error — los errores significan arreglar la configuración y volver a ejecutar)
- Falla por la razón correcta (falta la funcionalidad, no un error tipográfico)
- Una prueba que pasa inmediatamente significa que estás probando comportamiento existente — corrige la prueba
3. VERDE — escribe código mínimo
El código más simple que pasa la prueba. Sin funcionalidades especulativas, sin
"flexibilidad", sin refactorizar código adyacente. YAGNI. No añadas métodos solo para pruebas
(destroy(), reset()) a clases de producción — pon la limpieza en utilidades de prueba.
4. Verifica VERDE — obsérvala pasar
Ejecuta el comando de prueba enfocado, luego la suite completa. Confirma:
- La nueva prueba pasa
- Ninguna otra prueba se rompió (si lo hizo, arréglalo ahora — no lo omitas)
- La salida está limpia (sin advertencias, sin pruebas omitidas)
5. REFACTORIZA — limpia
Solo en verde: extrae ayudantes, mejora nombres, elimina duplicación. Ejecuta pruebas después de cada paso de refactorización. No añadas comportamiento. La refactorización pertenece a la etapa de revisión, no al ciclo de implementación rojo → verde.
6. Confirma el commit
Confirma la prueba y la implementación juntas como un solo corte vertical. Luego comienza la siguiente prueba que falla.
Corrección de errores — el Patrón Pruébalo
No empieces corrigiendo. Escribe una prueba que reproduzca el error (ROJO confirma que existe), luego corrige (VERDE demuestra que la corrección funciona). La prueba queda como guardián de regresión. Nunca corrijas un error sin una prueba de reproducción.
Verificar
- Cada nuevo comportamiento tiene una prueba que falló primero
- La suite completa pasa con el comando de prueba propio del repositorio
- Las correcciones de errores incluyen una prueba de reproducción que fallaba antes de la corrección
- Los nombres de las pruebas describen comportamiento, no implementación
- Ninguna prueba omitida o desactivada; ningún método solo para pruebas en código de producción
Referencias
- ${CLAUDE_PLUGIN_ROOT}/references/engineering-principles.md — disciplina que comparte toda habilidad
- references/test-strategy.md — pirámide de pruebas, jerarquía de dobles de prueba (Real > Fake > Stub > Mock), DAMP sobre DRY
- references/testing-anti-patterns.md — mal uso de mocks, métodos solo para pruebas, mocks parciales, funciones de compuerta
- references/mocking.md — cuándo simular, diseñar para ser simulable
- references/good-tests.md — ejemplos de pruebas buenas vs malas, pruebas tautológicas