tdd-workflow
Implementar Flujo de Desarrollo Guiado por Pruebas
También disponible en: DoubleslashSE
Los desarrolladores pierden tiempo depurando código sin pruebas. Esta habilidad aplica el ciclo RED-GREEN-REFACTOR para crear software confiable con confianza.
Descargar el ZIP de la skill
Subir en Claude
Ve a Configuración → Capacidades → Skills → Subir skill
Activa y empieza a usar
Pruébalo
Usando "tdd-workflow". Implementar una función para validar direcciones de email
Resultado esperado:
- Fase RED: Creada prueba 'should accept valid email format' - la prueba falla (sin implementación aún)
- Fase GREEN: Implementada validación mínima con regex - la prueba pasa
- Fase REFACTOR: Extraída la lógica de validación a función separada, mejorados los mensajes de error
Usando "tdd-workflow". Corregir excepción de puntero nulo en búsqueda de usuario
Resultado esperado:
- Fase RED: La prueba reproduce la excepción de puntero nulo - fallo confirmado
- Fase GREEN: Añadida verificación nula antes de acceder a propiedades del usuario - la prueba pasa
- Fase REFACTOR: Creado helper de búsqueda reusable null-safe usado en todo el código base
Auditoría de seguridad
SeguroAll static analysis findings are false positives. The arrow character (→) was misidentified as shell backtick execution. References to 'crypto' and 'reconnaissance' are pattern matching errors on plain text documentation. This is a safe TDD methodology guide. External commands are legitimately used for running test suites.
Factores de riesgo
⚙️ Comandos externos (1)
Puntuación de calidad
Lo que puedes crear
Desarrollo de Nuevas Funcionalidades
Crear funcionalidades confiables escribiendo pruebas primero, luego implementando código mínimo para pasar cada prueba.
Corrección de Errores con Protección de Regresión
Escribir una prueba que reproduzca el error, corregirlo, luego refactorizar con confianza de que el error permanece corregido.
Mejora de Calidad de Código del Equipo
Usar patrón TDD multiagente donde diferentes agentes escriben pruebas, implementan código y refactorizan.
Prueba estos prompts
Quiero implementar una función que [describe behavior]. Escribe primero una prueba que falle siguiendo la fase RED de TDD. La prueba debe describir claramente el comportamiento esperado.
Implementemos [feature] usando TDD. Paso 1: Escribir una prueba que falle. Paso 2: Escribir código mínimo para pasar. Paso 3: Refactorizar para mayor claridad. Guíame a través de cada fase.
Revisa esta prueba y restrúcturala usando el patrón AAA (Arrange, Act, Assert). Identifica qué datos necesitan configuración, qué código se ejecuta y qué resultado verificar.
Ejecuta una sesión TDD multiagente para [feature]. El Agente A escribe la prueba que falla, el Agente B implementa para pasar, el Agente C refactoriza. Coordina las transiciones entre fases.
Mejores prácticas
- Siempre observa que la prueba falle antes de escribir código de implementación - esto valida que la prueba funciona
- Escribe una aserción por prueba para aislar fallos y clarificar la intención
- Commit después de cada ciclo completo RED-GREEN-REFACTOR para mantener cambios pequeños y revisables
Evitar
- Escribir código antes de que la prueba falle - frustra el propósito de TDD y a menudo significa que no entiendes los requisitos
- Probar detalles de implementación como nombres de métodos privados - las pruebas deben verificar comportamiento, no estructura interna
- Múltiples aserciones por prueba - hace los fallos ambiguos y viola el principio de responsabilidad única