TDD: utilice la refactorización rojo-verde para obligar a la IA a dar pequeños pasos

Modo de fallo: "La IA hace lo correcto, pero no puede ejecutarse"

El tercer modo de fracaso en la charla de Matt: La dirección es correcta, pero no funciona.

La solución más directa es instalar una infraestructura de retroalimentación para la IA:

• TypeScript (sin escritura estática es una locura)
• Permitir que LLM acceda al navegador y vea la página por sí mismo
• Pruebas automatizadas

Pero Matt observó una cosa: Incluso con estos comentarios instalados, LLM no funciona bien. Tiende a escribir 500 líneas a la vez y luego piensa "oh, debería escribir, verifique eso". Esto es lo que el Programador Pragmático llama dejar atrás a tus faros: conduce más rápido de lo que los faros pueden iluminar y es sólo cuestión de tiempo antes de que choques contra la pared.

"The rate of feedback is your speed limit, which means you should be testing as you go, taking small deliberate steps. And the AI by default is really not very good at that."

Para solucionar este problema, debe obligar a la IA a detenerse paso a paso en el nivel de la herramienta. La respuesta de Matt es TDD: Probar primero puede forzar puntos de control.

Teoría clásica: la reconstrucción rojo-verde de Kent Beck

El ritmo estándar de TDD lo define Kent Beck en su libro de 2003 "Desarrollo basado en pruebas: con el ejemplo":

1. ROJO: Escribe una prueba fallida (describe qué hacer)
2. VERDE: Escriba el código lo suficientemente pequeño como para que la prueba pase
3. REFACTOR: Mejora la estructura del código bajo protección de prueba

Cada bucle es extremadamente corto, del orden de minutos. Hay comprobaciones automáticas (prueba aprobada/fallada) en cada paso.

Matt sigue directamente este ritmo, pero su SKILL.md pasa mucho tiempo hablando de un antipatrón: este es el núcleo.

Antipatrón clave: rojo y verde cortados horizontalmente

Mucha gente piensa que TDD significa "escribir todas las pruebas primero y luego escribir todas las implementaciones". Matt dice directamente que esto está mal en SKILL.md:

WRONG (horizontal slicing):
  RED:   test1, test2, test3, test4, test5
  GREEN: impl1, impl2, impl3, impl4, impl5

RIGHT (vertical slicing via tracer bullets):
  RED→GREEN: test1→impl1
  RED→GREEN: test2→impl2
  RED→GREEN: test3→impl3
  ...

¿Por qué está mal la horizontal? SKILL.md dio tres razones:

1. Tests written in bulk test imagined behavior, not actual behavior
2. You end up testing the shape of things (data structures, function signatures) rather than user-facing behavior
3. Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine

Dicho humano: Escribir todas las pruebas de una sola vez es probar lo que hay en tu cabeza, no el código real. Cuando escribe impl3, se da cuenta de que el diseño de test1 es incorrecto, pero en este momento, test2/test3/test4 están todos acoplados al diseño incorrecto. Regrese y haga cambios.

El enfoque correcto es probar una implementación y luego abrir el siguiente par después de escribir un par. Después de completar cada par y haber aprendido algo de esta implementación, el siguiente par de pruebas se puede diseñar basándose en la experiencia real, no en la imaginación.

Estructura de texto completo de habilidad

engineering/tdd/SKILL.md es una de las habilidades más largas que Matt ha escrito porque TDD en sí tiene muchos matices. La estructura central es la siguiente:

Filosofía

Core principle: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.

Good tests are integration-style: they exercise real code paths through public APIs. They describe what the system does, not how it does it. A good test reads like a specification.

Bad tests are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly). The warning sign: your test breaks when you refactor, but behavior hasn't changed.

Recuerde un diagnóstico: Si cambia el nombre de una función interna, la prueba se arrodillará; entonces esta prueba está probando la implementación en lugar del comportamiento, lo cual es una mala prueba.

Flujo de trabajo (con lista de verificación)

1. Planning

Alinearse con los usuarios antes de escribir código:

[ ] Confirm with user what interface changes are needed
[ ] Confirm with user which behaviors to test (prioritize)
[ ] Identify opportunities for deep modules (small interface, deep impl)
[ ] Design interfaces for testability
[ ] List the behaviors to test (not implementation steps)
[ ] Get user approval on the plan

Pregunta clave: "¿Cómo debería verse la interfaz pública? ¿Qué comportamientos es más importante probar?"

"You can't test everything. Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case."

Este es muy contrario a la intuición. De forma predeterminada, la IA querrá agotar todos los casos extremos, pero Matt enfatiza la prioridad: no vale la pena medir todos los comportamientos, y centra la potencia de fuego en el camino principal.

2. Tracer Bullet

Escribe una prueba que verifique una cosa:

RED:   Write test for first behavior → test fails
GREEN: Write minimal code to pass → test passes

Esta es una "bala trazadora": dispárela primero y compruebe la mira. Matt enfatizó que este trabajo debe ser de un extremo a otro: no escribir el esquema primero, luego escribir la API y luego escribir la interfaz de usuario, sino cortar la ruta más delgada que recorra toda la pila.

3. Incremental Loop

Repita para cada comportamiento posterior ROJO→VERDE:

RED:   Write next test → fails
GREEN: Minimal code to pass → passes

Reglas:

• Una prueba a la vez
• Escribe sólo el código suficiente para pasar la prueba actual.
• No predecir pruebas futuras
• Las pruebas se centran en el comportamiento observable.

"No predecir" es particularmente importante. La IA no puede evitar pensar: "Esta función debe ser compatible con X de todos modos, agreguémosla por cierto", y esto inicia el corte horizontal.

4. Refactor

Una vez pasadas todas las pruebas, busque oportunidades de refactorización:

[ ] Extract duplication
[ ] Deepen modules (move complexity behind simple interfaces)
[ ] Apply SOLID principles where natural
[ ] Consider what new code reveals about existing code
[ ] Run tests after each refactor step

Never refactor while RED. Get to GREEN first.

Refactorizar en rojo = cambiar pruebas y código al mismo tiempo = no sabes si la prueba es incorrecta o el código es incorrecto. Primero verde, luego refactorizar.

Per-Cycle Checklist

Al final de cada ciclo rojo y verde, Matt le pide a la IA que se autoverifique:

[ ] Test describes behavior, not implementation
[ ] Test uses public interface only
[ ] Test would survive internal refactor
[ ] Code is minimal for this test
[ ] No speculative features added

Estos cinco puntos se utilizan para identificar malas pruebas y una implementación excesiva. La autocomprobación de la IA puede evitar los errores más comunes.

Uso real: del problema al PR

/tdd es el siguiente paso en el flujo de trabajo de Matt desde /to-issues. Dado un problema de corte vertical, el proceso es:

你: 实现 issue #43
    ↓
/tdd
    ↓
Claude 读 issue acceptance criteria
    ↓
Claude 探索代码库 → 找到 CONTEXT.md → 用项目术语
    ↓
Planning 阶段:
    - 列出准备改的接口
    - 列出准备测的行为（按优先级排序）
    - 让你点头
    ↓
Tracer Bullet:
    - RED: 写第一个测试（基于 acceptance criteria 第 1 条）
    - 跑测试，确认 fail
    - GREEN: 写最小实现
    - 跑测试，确认 pass
    ↓
Incremental Loop:
    - 每个 acceptance criteria 一个 RED→GREEN
    ↓
Refactor:
    - 看 deep module 提取机会
    - 每次重构后跑全套测试
    ↓
PR

En cada ciclo rojo y verde, la IA se detendrá y le dará un estado: "la prueba falla"/"la prueba pasa, aquí está la diferencia". Estas pausas son el antídoto para dejar atrás los faros: la IA no tiene ninguna posibilidad de trazar mil líneas de una sola vez.

Acerca de Mock: la fuerte opinión de Matt

SKILL.md menciona específicamente los peligros de las burlas; también proporciona un mocking.md por separado. Ideas centrales:

"Bad tests... mock internal collaborators."

Colaboradores internos simulados = acoplamiento 1:1 entre pruebas e implementación = el equipo de pruebas se arrodilla al refactorizar. La preferencia de Matt es pruebas de estilo de integración: intente utilizar una base de datos real (en memoria o contenedores de prueba), HTTP real (MSW) y un sistema de archivos real (tmp dir). Solo burlándose de límites realmente costosos o inestables (como llamadas a la API de OpenAI).

Esto es contrario a la situación actual de muchos equipos: la mayoría de las bibliotecas de códigos están llenas de pruebas unitarias y hay más simulaciones que código real. Matt emitió un juicio en su discurso: Buena base de código = base de código fácil de probar. Si tienes que simular un montón de cosas para probar, significa que hay un problema con la estructura del código y primero debes cambiar la arquitectura (ve a /improve-codebase-architecture).

El nuevo significado de TDD en la era de la IA

Cuando Kent Beck escribió ese libro hace 23 años, el beneficio principal de TDD era que "la gente no escribía código incorrecto". En la era de la IA, TDD tiene un significado adicional:

Es el único "criterio de éxito" que la IA puede entender.

Matt citó las sabias palabras de Karpathy más adelante en su discurso:

La mejor forma de "criterios de éxito" es prueba: es verificable por máquina, binario y no se puede cuestionar. Darle a la IA un conjunto de pruebas + "déjelo pasar" es diez veces más confiable que darle a la IA una descripción de los requisitos + "implemente".

Por lo tanto, /tdd no es sólo una herramienta de control de calidad: es la interfaz de entrada al bucle del agente. Cada ciclo rojo y verde es una "entrada → acción → retroalimentación" completa. La IA aprende la verdadera situación de esta implementación en el ciclo y el siguiente ciclo será más preciso.

Cómo instalar y usar

npx skills@latest add mattpocock/skills

Marque tdd + setup-matt-pocock-skills.

Si ahora utiliza principalmente Codex, tome el control del producto de instalación en .agents/skills/ y escriba el flujo de trabajo a nivel de proyecto, los comandos de prueba y las reglas de seguimiento de emisiones en AGENTS.md. La esencia de /tdd de Matt es el ciclo de refactorización rojo-verde, no vinculado al Código Claude.

Método de llamada:

• Directo: /tdd - deja que infiera qué medir a partir del contexto de la conversación actual
• Recuperar problema: /tdd implement #43 - buscará el problema y luego lo abrirá
• Corrección de error: /tdd reproduce this bug then fix it - Primero escribirá una prueba fallida que pueda reproducir el error y luego lo solucionará.

Notas

No apto para todas las tareas. Scripts únicos, código de exploración del área de juegos, ajuste de la interfaz de usuario: no use TDD, ralentizará el ritmo. El propio Matt dijo que TDD es adecuado para código que "tiene un valor duradero y necesita ser mantenido".

Primero prepare la infraestructura de prueba. Si el proyecto no ha instalado el marco de prueba (Vitest / Jest / Playwright, etc.), instálelo primero y luego use /tdd; de lo contrario, lo instalará primero, pero hay muchas preguntas en ese paso.

No permita que agregue automáticamente pruebas e2e. e2e es lento y nítido, y el ritmo TDD es de nivel de minutos. /tdd tiene como valor predeterminado la prueba de integración en lugar de e2e, pero puede indicarle explícitamente "solo unidad + integración, no e2e".

La fase de reconstrucción es la más fácil de salir de control. Después de que la IA obtenga el estado VERDE, refactorizará un montón de cosas con entusiasmo: mírelas fijamente y ejecutará pruebas después de cada refactorización. Esta parte es un área de alto riesgo para la desviación de la IA.

Recursos de referencia

Siguiente artículo: Mejorar la arquitectura de la base de código: reconstruir módulos superficiales en módulos profundos - El mantenimiento periódico permite que la IA se ejecute en su base de código a largo plazo.