tdd-workflow

Visión general de la skill tdd-workflow

Qué hace tdd-workflow

tdd-workflow es una skill de ejecución test-first para trabajo de funcionalidades, correcciones de errores y refactorizaciones. Está diseñada para ayudarte a pasar de una idea de implementación aproximada a código verificado con pruebas unitarias, de integración y E2E, en lugar de parchearlo después.

Quién debería instalarla

Instala la skill tdd-workflow si quieres un ciclo de desarrollo más estricto para código de aplicaciones, APIs, cambios de UI o trabajo con mucha automatización. Es especialmente útil cuando necesitas cobertura predecible, tratamiento explícito de casos límite y un orden de operaciones repetible para trabajo de automatización de pruebas.

Por qué destaca

El valor principal de tdd-workflow es la disciplina: las pruebas van antes que el código, los objetivos de cobertura son explícitos y el flujo espera evidencia en cada etapa. Eso la hace más útil para tomar decisiones que un prompt genérico de “escribe pruebas”, porque empuja al agente a planificar, verificar y dejar puntos de control en lugar de saltar directamente a la implementación.

Cómo usar la skill tdd-workflow

Instálala y actívala

Usa el flujo tdd-workflow install para este repo, o añádela mediante la ruta de skills de tu Claude Code si tu configuración gestiona las skills manualmente. Lo importante es que el agente vea la skill antes de empezar a programar, no después de que ya exista un primer borrador.

Dale a la skill la forma correcta de tarea

El patrón tdd-workflow usage funciona mejor cuando tu solicitud nombra el cambio, el riesgo y la prueba esperada. Entrada débil: “arregla el login”. Entrada sólida: “añade validación de restablecimiento de contraseña, cubre los estados de error de la API y de la UI, y mantén sin cambios el contrato actual de autenticación”. La segunda versión le da a la skill suficiente estructura para escribir primero las pruebas y elegir la mezcla adecuada de cobertura unitaria, de integración y E2E.

Lee primero estos archivos

Empieza por SKILL.md y luego revisa README.md, AGENTS.md, metadata.json y cualquier carpeta rules/, resources/, references/ o scripts/ si existen. En este repo, SKILL.md es el único archivo de origen visible, así que trátalo como la especificación canónica del flujo y adáptalo al stack de pruebas y a las restricciones del proyecto de destino.

Sigue el flujo en orden

Usa la skill para definir primero las pruebas que fallan, luego implementa el cambio de código más pequeño que las haga pasar y después ejecuta la siguiente capa de validación. Si tu repositorio admite puntos de control en Git, conserva un commit después de cada etapa de TDD para que la traza de evidencia siga siendo legible y reversible. Esto importa sobre todo cuando el trabajo abarca lógica de backend, límites de API y comportamiento en el navegador.

Preguntas frecuentes sobre la skill tdd-workflow

¿tdd-workflow es solo para cambios grandes?

No. La skill tdd-workflow también es útil para correcciones pequeñas, especialmente cuando el error es sutil o puede reaparecer fácilmente. Tiene menos valor para cambios triviales de texto o ajustes de configuración de una sola línea que no se benefician de una verificación por etapas.

¿Necesito primero una suite de pruebas madura?

No necesariamente, pero sí necesitas suficiente tooling de pruebas para que el flujo sea real. Si un proyecto no tiene una configuración práctica de pruebas unitarias, de integración o E2E, la guía tdd-workflow seguirá ayudando con el proceso, pero quizá haya que adaptar los objetivos de cobertura a los límites reales de pruebas del repo.

¿En qué se diferencia de un prompt normal?

Un prompt normal puede pedir código y pruebas al mismo tiempo. tdd-workflow cambia el orden y las reglas de decisión: primero las pruebas, expectativas de cobertura explícitas y validación por etapas según el tipo de prueba. Eso suele reducir la incertidumbre cuando haces automatización de pruebas o trabajas en varias capas del stack.

¿Es apta para principiantes?

Sí, si te sientes cómodo leyendo fallos de pruebas y siguiendo un ciclo paso a paso. A los principiantes les beneficia la estructura, pero deben mantener la tarea acotada y aportar criterios de aceptación claros; si no, el flujo puede sentirse más rígido que útil.

Cómo mejorar la skill tdd-workflow

Aporta criterios de aceptación más precisos

La mejor entrada para tdd-workflow dice qué debe funcionar, qué no debe cambiar y cómo se comprobará el éxito. Incluye entradas, salidas, casos de fallo y cualquier restricción de compatibilidad. Por ejemplo: “rechaza email vacío, conserva la forma de respuesta existente y cubre tanto el recorrido del navegador como el manejo de errores de la API”.

Pide la mezcla de pruebas adecuada

La skill funciona mejor cuando indicas dónde está el riesgo. Si el cambio toca lógica de negocio, pide primero pruebas unitarias. Si atraviesa límites de servicio, exige cobertura de integración. Si importa el recorrido del usuario, añade comprobaciones E2E. Así evitas que el flujo abuse de un solo tipo de prueba y pase por alto el modo real de fallo.

Vigila los fallos más comunes

El problema más frecuente es sobreimplementar antes de que las pruebas estén estables. Otro es tratar una cobertura del 80%+ como una casilla que marcar, en vez de como una señal para cubrir casos límite, fronteras y rutas de error. Si la primera pasada es demasiado amplia, reduce el alcance y vuelve a ejecutar el ciclo de tdd-workflow usage con un solo escenario cada vez.

Itera con evidencia

Después de la primera salida, revisa qué prueba falló, qué comportamiento quedó demostrado y qué sigue sin probarse. Luego pide el siguiente incremento más pequeño en lugar de una reescritura completa. Para tdd-workflow for Test Automation, esto suele significar ajustar selectores, afirmaciones explícitas y cobertura de casos negativos antes de ampliar a más flujos de usuario.