test-driven-development

Visión general de la skill test-driven-development

Lo que realmente hace la skill test-driven-development

La test-driven-development skill le da a un agente de IA un flujo TDD estricto para trabajo de funcionalidades, corrección de bugs y cambios de comportamiento: primero escribir una prueba, confirmar que falla por la razón correcta, escribir el mínimo código de producción para que pase y, después, refactorizar con seguridad. Su valor principal no es “escribir tests también”, sino imponer una secuencia en la que la implementación quede guiada por comportamiento ejecutable.

Para quién encaja mejor esta skill

Esta test-driven-development skill encaja mejor con desarrolladores que usan IA sobre repositorios reales donde la corrección importa: funcionalidades de aplicación, lógica de servicios, correcciones de bugs, refactors y prevención de regresiones. Es especialmente útil cuando quieres que el modelo deje de saltar directamente a implementar y, en cambio, produzca pasos más pequeños y verificables.

El trabajo real que viene a resolver

La mayoría instala test-driven-development porque los prompts de programación genéricos suelen generar primero el código y adaptar los tests después. Esta skill cambia ese comportamiento. Te ayuda a obtener implementaciones ancladas en pruebas que fallan al inicio, lo que hace al agente más fácil de revisar y menos propenso a inventar comportamientos no verificados.

Qué la diferencia de un prompt genérico de “escribe tests”

Lo que la distingue es la “ley de hierro” que define la skill: no hay código de producción sin una prueba fallando antes. Eso es bastante más estricto que un prompting normal. La skill también insiste en verificar que el fallo inicial sea el fallo correcto, no simplemente cualquier resultado en rojo, una protección práctica que muchas explicaciones superficiales de TDD pasan por alto.

Límites importantes antes de instalarla

Esta es una skill de proceso, no un toolkit de testing ligado a un framework concreto. No va a decidir por ti toda la arquitectura de pruebas, y no incluye scripts auxiliares ni referencias extensas más allá de SKILL.md y testing-anti-patterns.md. Si necesitas guía profunda de configuración para Jest, Pytest, JUnit o Playwright, esta skill funciona mejor como capa de flujo de trabajo que como manual completo de testing.

Cómo usar la skill test-driven-development

Instalar la skill test-driven-development

Instálala desde el repositorio con:

npx skills add https://github.com/obra/superpowers --skill test-driven-development

Si tu entorno admite descubrimiento local de skills, confirma que la skill aparezca como test-driven-development y que esté disponible para el agente antes de empezar trabajo de funcionalidades.

Lee primero estos archivos

Para esta instalación de test-driven-development y su flujo de uso, empieza por:

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

Lee primero SKILL.md para entender el flujo y las restricciones. Después, revisa testing-anti-patterns.md si tu tarea incluye mocks, aislamiento, pruebas de UI o cualquier tentación de añadir costuras pensadas solo para tests dentro del código de producción.

Ten claro el mínimo de contexto que necesita la skill

La skill funciona mejor cuando le das:

• la funcionalidad, bug o cambio de comportamiento
• los archivos relevantes o los límites del módulo
• el framework de testing que ya usa el repositorio
• el comportamiento esperado visible para usuarios o para el sistema
• cualquier restricción sobre la forma de la API, compatibilidad hacia atrás o rendimiento

Sin ese contexto, el agente puede aplicar TDD de forma mecánica, pero puede elegir un nivel de prueba incorrecto o crear tests forzados que se adapten mejor a la herramienta que al código base.

Convierte una petición vaga en un prompt listo para TDD

Prompt débil:

Add support for password reset.

Prompt más sólido:

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

La versión más sólida le da al agente suficiente contexto para elegir bien la primera prueba y respetar el ciclo red-green-refactor.

Usa la skill como un flujo paso a paso, no como una sola generación grande

Un patrón práctico de uso de test-driven-development es:

1. Pide solo la primera prueba que falle.
2. Revisa si el fallo apunta al comportamiento que buscas.
3. Pide la implementación mínima para hacerla pasar.
4. Pide refactorización solo después de estar en verde.
5. Repite con la siguiente porción pequeña de comportamiento.

Esto suele dar mejor resultado que pedir la funcionalidad completa de una vez, porque la skill está diseñada para avanzar en incrementos pequeños y validados.

Verifica bien la fase “red”

Un detalle clave en esta guía de test-driven-development es que no basta con que una prueba falle. El fallo debe demostrar que la prueba apunta al comportamiento ausente correcto. Si falla por errores de importación, fixtures rotos o problemas de setup no relacionados, el ciclo en realidad todavía no ha empezado.

Al hacer el prompt, pide explícitamente al agente que explique por qué falla la prueba y por qué ese fallo es el correcto.

Elige bien la primera prueba

La mejor primera prueba suele apuntar al cambio de comportamiento más pequeño que tenga sentido desde fuera. Buenos candidatos:

• la reproducción de un bug
• una regla de negocio
• un cambio en la respuesta de un endpoint
• el comportamiento de un método de dominio
• una interacción de UI con impacto claro para el usuario

Malos puntos de partida:

• escenarios end-to-end gigantes
• cobertura amplia basada en snapshots
• pruebas que fijan demasiado pronto detalles internos de implementación

Aplica la guía de anti-patrones cuando aparezcan mocks

El archivo de apoyo testing-anti-patterns.md importa especialmente si el agente empieza a abusar de los mocks. La skill advierte con claridad contra probar el comportamiento del mock en vez del comportamiento real. Esto es especialmente relevante en test-driven-development for Test Automation, donde los agentes de IA suelen crear assertions sobre placeholders simulados porque son más fáciles de satisfacer que salidas reales.

Si una prueba afirma que se renderizó un mock, que un mock fue llamado de una forma trivial o que hubo que añadir un método solo para tests al código de producción, detén el proceso y redefine el alcance de la prueba.

Pide al agente que respete la ley de hierro

Si el modelo ya redactó una implementación, la guía de la propia skill es estricta: hay que borrar el código de producción y reiniciar desde una prueba que falle. En la práctica no hace falta dramatizar, pero sí conviene indicarle al agente que ignore la implementación especulativa previa y regenere desde una secuencia test-first.

Redacción útil:

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

Ajusta la skill a la pila de testing de tu repositorio

La skill está centrada en el proceso, así que conviene anclarla a tu stack:

• pytest para servicios en Python
• Jest o Vitest para lógica en JS/TS
• RSpec para Ruby
• JUnit para Java
• Playwright o similares solo cuando el comportamiento realmente pertenezca al nivel del navegador

Si tu repo ya tiene una pirámide de testing sólida, indícale al agente dónde encaja este cambio. Si no, el modelo puede inclinarse por el estilo de prueba más visible en vez del más barato y útil.

Ejemplo de prompt para trabajo real sobre repositorios

Un buen prompt para la test-driven-development skill se parece a esto:

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

Este prompt aporta comportamiento, ubicación, framework y criterios de revisión.

Preguntas frecuentes sobre la skill test-driven-development

¿Merece la pena instalar test-driven-development si ya conozco TDD?

Sí, si tu problema principal es conseguir que los agentes de IA sigan TDD de verdad en lugar de limitarse a hablar de ello. La test-driven-development skill aporta valor menos como formación y más como restricción de comportamiento para el modelo.

¿Es apta para principiantes?

En general, sí. El flujo es simple y explícito. La parte más difícil para principiantes suele ser elegir bien la primera prueba y el nivel de test adecuado. Si estás empezando con testing, úsala primero en correcciones pequeñas de bugs y no en funcionalidades nuevas amplias.

¿Cuándo encaja mal test-driven-development?

Encaja peor en prototipos desechables, código generado o cambios puramente de configuración, salvo que el riesgo de errores sea alto y la revisión humana siga exigiendo disciplina test-first. La guía original trata estos casos explícitamente como excepciones que conviene comentar con una persona del equipo.

¿En qué se diferencia del prompting habitual?

Los prompts normales suelen decir “implementa X y añade tests”. Esta skill cambia el orden del trabajo y trata ese orden como algo no negociable. Esa secuencia es el valor real, porque reduce implementación alucinada y mejora la capacidad de revisión.

¿Esta skill también cubre la configuración del framework?

No en profundidad. La instalación de test-driven-development es sencilla, pero la skill en sí no ofrece documentación extensa de setup para frameworks concretos. Da por hecho que puedes orientar al agente hacia tu stack de testing existente o hacia las convenciones del repositorio.

¿Puedo usar test-driven-development para refactorizar?

Sí. Encaja bien en refactors donde el comportamiento debe mantenerse estable. El patrón práctico es bloquear primero el comportamiento actual con tests y, después, refactorizar con la protección de tener las pruebas en verde.

¿Sirve para UI y pruebas end-to-end?

A veces, pero con cuidado. En trabajo de UI, el archivo de anti-patrones es especialmente importante porque la IA puede desviarse hacia assertions sobre la presencia de mocks o artefactos de implementación. Empieza por el comportamiento real más pequeño del usuario que puedas verificar.

Cómo mejorar la skill test-driven-development

Da comportamiento esperado, no ideas de solución

Para conseguir un mejor uso de test-driven-development, describe el comportamiento esperado y las restricciones en lugar de dictar la implementación. TDD funciona mejor cuando el test define resultados y el código emerge a partir de esas comprobaciones.

Mejor input:
Users should see an error when uploading files over 10MB.

Peor input:
Add a fileSizeValidator class and call it from the controller.

La primera formulación deja espacio para una implementación mínima más limpia.

Especifica el nivel de prueba que quieres

Muchos resultados flojos vienen de un alcance de prueba mal elegido. Dile al agente si quieres:

• lógica de negocio a nivel unitario
• integración alrededor de un servicio o API
• comportamiento a nivel navegador

Esta sola decisión suele importar más que cualquier otro detalle del prompt.

Fuerza incrementos más pequeños

Un fallo habitual es pedir demasiado en un solo ciclo. Si el modelo escribe a la vez una suite amplia de tests y una implementación grande, acótalo:

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

Así mantienes intacto el bucle de test-driven-development.

Exige una explicación de por qué la primera prueba es la correcta

Pide al agente que justifique:

• por qué esta prueba es la porción útil más pequeña
• qué fallo exacto se espera
• por qué ese fallo demuestra que el comportamiento falta

Esto mejora la calidad porque hace visibles suposiciones ocultas antes de empezar a implementar.

Detecta los anti-patrones desde el principio

Las caídas de calidad más frecuentes son:

• probar mocks en vez de comportamiento real
• introducir métodos solo para tests en código de producción
• escribir primero tests que ya pasan y llamarlo TDD
• elegir assertions atadas a detalles de implementación
• saltarse la fase de refactor una vez todo está en verde

Si ves uno de estos problemas, detén el ciclo y pide una primera prueba corregida en lugar de ir parcheándolo.

Da explícitamente las convenciones del repositorio

La skill mejora cuando le indicas:

• convenciones de nombres para tests
• dónde viven los tests
• patrones de fixtures
• política de mocking
• estilo de assertions preferido

Como el repositorio solo incluye material de apoyo ligero, estas convenciones locales mejoran de forma material la calidad de salida.

Itera después de la primera respuesta

Después del primer resultado, no pidas simplemente “más”. Haz preguntas de seguimiento concretas:

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

Esta es la forma de mayor impacto para mejorar en la práctica la test-driven-development skill: mantener al agente dentro del ciclo en lugar de dejar que se adelante.

Combínala con criterio humano en las excepciones

La skill es estricta a propósito. Esa es una fortaleza, pero también puede aplicarse de más. Si la tarea es un cambio puramente de configuración, una regeneración de código generado o un prototipo desechable, conviene preguntarse si el coste de aplicar TDD completo merece la pena. Los mejores resultados llegan cuando usas la skill allí donde la secuencia test-first cambia la calidad de las decisiones, no simplemente allí donde puede aplicarse.