/test-driven-development
Descripción
¿Qué hace? /test-driven-development impone estrictamente el ciclo TDD: primero escribe el test que falla (RED), luego el mínimo código para que pase (GREEN), finalmente refactoriza manteniendo los tests en verde (REFACTOR).
Tiene hard gates que bloquean avanzar si el test no falla primero: Claude literalmente no puede escribir código de implementación sin antes tener un test fallido. Esto garantiza cobertura real del código y evita los tests escritos después de la implementación que solo verifican lo que ya funciona.
Ejemplos de uso
Claude primero escribe los tests: precio(verano, coupe) === 89, precio(invierno, coupe) === 65, precio(verano, suv) === 120. Los tests fallan (RED). Luego implementa la función mínima para que pasen (GREEN). Finalmente refactoriza para que el código sea limpio sin romper ningún test. El resultado: código con cobertura real desde el principio.
/test-driven-development Implementar función de cálculo de precio con descuento por temporada para sistema de alquiler de cochesHay decenas de casos edge en la validación de email. Con TDD, Claude escribe primero los tests de cada caso (email sin @, dominio sin punto, dominios desechables conocidos...) y luego implementa la función que los pasa todos. Sin TDD, esos casos edge suelen descubrirse en producción.
/test-driven-development Función de validación de email que detecta formatos incorrectos y dominios desechablesCuándo usarlo
Usa /test-driven-development para cualquier funcionalidad donde la calidad y fiabilidad sean prioritarias: lógica de negocio, funciones de cálculo, validaciones, APIs. La hard gate es la característica clave: Claude no puede avanzar sin el test fallido primero. Esto garantiza que los tests son reales y no retroactivos.