TDD en la era de la IA: deje que el modelo llegue primero a la luz roja

Hablemos primero de la conclusión.

Después de que AI escribe código, TDD no está desactualizado, pero ha cambiado de posición.

En el pasado, cuando hablábamos de TDD, a menudo hablábamos de la autodisciplina de los programadores: escribir pruebas primero, luego escribir la implementación y refactorizar en pequeños pasos. Cuando se trata de programación de IA, se parece más a un sistema de frenos. Porque lo que el modelo hace mejor es también lo más peligroso: puede escribir rápidamente un gran fragmento de código que parece completo.

Si le pide que implemente una función, puede darle:

• un archivo de implementación
• un conjunto de pruebas
• una explicación
• Una palabra "hecho"

La cuestión es que "parecer completo" no se hace en el sentido de ingeniería. Para completar en un sentido de ingeniería, al menos responda:

¿Este comportamiento está definido por una prueba fallida explícita? ¿Esta falla se volvió verde debido a la implementación? Después de ponerse verde, ¿hemos ordenado el código sin cambiar el comportamiento?

Es por eso que se vuelve a hablar de TDD en la era de la IA.

No se trata de hacer que el proceso parezca avanzado, sino de reemplazar la "confianza en el modelo" por "confianza en la retroalimentación".

1. Malentendido común: TDD no es "escribir pruebas primero"

Mucha gente odia el TDD porque lo entiende como un ritual:

先写测试。
再写代码。
最后跑一下。

Esto es ciertamente aburrido y puede convertirse fácilmente en formalismo.

El TDD verdaderamente útil no es "los archivos de prueba aparecen temprano", sino "las fallas aparecen lo suficientemente temprano".

La clave no está en probar, sino en rojo.

El primer paso de TDD se llama ROJO, no PRUEBA.

ROJO significa: escriba primero una prueba para que el sistema falle claramente. Para que esto falle deben ser ciertas tres cosas:

1. Falla.
2. Falla porque la conducta objetivo no existe.
3. Falla de la forma esperada.

Si el rojo no se ve primero, el verde que sigue no tiene sentido.

Por ejemplo, desea implementar slugify("Hello World") -> "hello-world". Un RED valioso no es "Escribí un archivo de prueba", sino:

Test: tests/test_slugify.py
Command: pytest tests/test_slugify.py -q
Failure: NameError: name 'slugify' is not defined
Reason: 目标函数还不存在，符合预期

Aquí es cuando la prueba se convierte en especificación. Te dice: Para lograr el siguiente paso, sólo necesitas hacer realidad este comportamiento.

Primero se pone verde y luego inventa la prueba, normalmente inventa la historia.

Es fácil para la IA ir por el otro lado: escribir la implementación primero y agregar las pruebas más tarde.

Esta es una experiencia fluida. Cuando vea que el código se ha ejecutado y las pruebas están realizadas, se sentirá "casi" en su corazón. Pero tiene un problema fatal: es probable que la prueba sea sólo una implementación retroactiva de la implementación actual.

No se trata de preguntar "cuáles deberían ser los requisitos", sino "cómo escribir el código actual para que pueda aprobarse fácilmente".

Es por eso que las pruebas de escritura de IA suelen tener estos olores:

• Las afirmaciones son demasiado específicas para la implementación actual.
• Hay demasiadas burlas y no se miden los límites reales.
• solo prueba el camino feliz
• Para hacer que el código existente pase, haga afirmaciones muy amplias.
• Ninguna prueba puede demostrar que el código antiguo era originalmente incorrecto.

TDD requiere lo contrario: primero dejar que los requisitos fallen y luego dejar que el código se ponga al día con los requisitos.

2. Por qué TDD es más necesario en la era de la IA

La principal contradicción de la programación de IA no es que "el código se escribe lentamente", sino que "la retroalimentación llega tarde".

Sin TDD, normalmente trabajas así:

描述需求 -> AI 写一堆代码 -> 人肉看 diff -> 跑一下 -> 发现问题 -> 回头修

Las preguntas se acumularán hasta el final. Para cuando descubras que está mal, es posible que se hayan mezclado tres categorías de cosas:

• Malentendido de los requisitos.
• La ruta de implementación es incorrecta.
• La refactorización rompe el comportamiento antiguo.

La función de TDD es acortar esta larga cadena.

Le da al modelo un objetivo decidible.

"Escribir con elegancia" no es el objetivo.

"Volver automáticamente a la página de inicio de sesión después de que expire el estado de inicio de sesión del usuario" no es lo suficientemente específico.

Un mejor objetivo sería:

当 access token 过期时：
1. 请求返回 401。
2. 客户端清理本地 session。
3. 用户被重定向到 /login。
4. 原始目标地址被保存在 redirect 参数里。

Vaya un paso más allá y convierta uno de ellos en una prueba fallida:

given expired session
when user opens /settings
then app redirects to /login?redirect=/settings

En este momento, la IA ya no está adivinando "cómo manejar la expiración del estado de inicio de sesión", sino completando un comportamiento claro.

Divide tareas grandes en pequeños bucles cerrados

El lugar más fácil para que la IA pierda el control es hacerlo todo de una vez.

Deje que implemente el inicio de sesión, los permisos, el token de actualización, los mensajes de error y los saltos de ruta a la vez, y al final obtendrá una gran diferencia. Podría funcionar, pero el costo de la revisión es alto. Tienes que juzgar el negocio, el estado, el enrutamiento, los límites, las pruebas y la refactorización al mismo tiempo.

El ritmo de TDD se parece más a esto:

一个行为 -> 一个失败测试 -> 最小实现 -> 变绿 -> 再下一个行为

Avance sólo una pequeña cantidad a la vez. Es lo suficientemente pequeño como para que puedas entenderlo, lo suficientemente pequeño como para que a la IA le resulte difícil inventar historias y lo suficientemente pequeño como para poder localizar rápidamente cuando falla.

Limita el modelo para "jugar sin problemas"

Un problema común con la IA es el exceso de entusiasmo.

Le pides que solucione un error en los límites y extrae el ayudante; le pide que agregue una prueba y cambia la implementación; le pides que refactorice y cambia su comportamiento.

TDD utiliza fases para separar estas acciones:

Esta tabla es más útil que "Tenga cuidado". Le permite al modelo saber en qué etapa se encuentra y facilita que los humanos detecten violaciones de límites.

3. Reconstrucción del rojo y del verde: tres puertas, no tres lemas

“Rojo, Verde, Refactor” podría ser fácilmente un eslogan. En uso real, debería verse como tres puertas. Cada vez que pases por una puerta, deberás dejar constancia.

La primera puerta: ROJA, lo que demuestra que no se han cubierto las necesidades.

Las preguntas más importantes durante la fase RED son:

Si esta prueba falla, ¿prueba que todavía nos falta una conducta objetivo?

UN MAL ROJO:

assert True

Tampoco es un muy buen ROJO:

assert "hello" in format_title("Hello World")

Es demasiado ancho. También pasan muchas implementaciones defectuosas.

Mejor ROJO:

def test_slugify_lowercases_and_uses_hyphen():
    assert slugify("Hello World") == "hello-world"

Esta prueba es pequeña, pero está clara. Especifica entradas, salidas y comportamiento.

Segunda puerta: VERDE, solo deja pasar la prueba actual

La fase VERDE no se trata de escribir la arquitectura final.

Sólo tiene una misión: pasar la prueba actualmente fallida con la menor cantidad de código.

Esta afirmación suena contraintuitiva. A mucha gente le preocupa si una "implementación mínima" será demasiado fea. Sí, a veces puede ser feo. Pero su valor radica en mantener la presión del diseño.

Si la primera prueba es:

def test_slugify_lowercases_and_uses_hyphen():
    assert slugify("Hello World") == "hello-world"

Un VERDE aceptable podría ser simplemente:

def slugify(text: str) -> str:
    return text.lower().replace(" ", "-")

No es necesario que admitas chino, acentos, puntuación continua, emojis y casos especiales de SEO de inmediato. Estos deberían ser impulsados ​​por pruebas posteriores.

La tercera puerta: REFACTOR, solo cambia la estructura, no el comportamiento

La etapa REFACTOR es la más fácil de confundir para la IA.

Interpretará "ordenar el código" como "mejorarlo por cierto". Esto no funcionará. La definición de refactorización es muy limitada: el comportamiento externo permanece sin cambios, pero la estructura interna mejora.

Una buena refactorización se ve así:

• Cambiar el nombre de la variable por uno más preciso.
• Extraer expresiones repetidas
• Eliminar ramas condicionales que sean demasiado profundas.
• Mover las ubicaciones de las funciones para aclarar las responsabilidades del módulo

Una mala refactorización se ve así:

• Ahora se admiten nuevas entradas
• El mensaje de error se ha cambiado fácilmente.
• Se cambiaron las dependencias fácilmente
• Cambió convenientemente la afirmación de la prueba.

Los criterios de juicio son simples:

Si esta confirmación se llamó simplemente refactor:, debería ser del mismo color verde antes y después de la prueba, y el comportamiento del usuario debería ser el mismo.

4. El sabor de las buenas pruebas

TDD no se trata de que más pruebas sean mejores. La IA también es muy buena para generar un montón de pruebas que tienen poco valor.

Lo más importante es probar el sabor.

Las buenas pruebas son como especificaciones

Una buena prueba debería leerse como una especificación comercial:

当用户没有权限时，保存按钮不可点击。
当标题为空时，表单显示错误信息。
当重复提交同一个请求时，只创建一条记录。

Se ocupa del comportamiento externo, no de lo que se hace internamente.

Las malas pruebas parecen notas de implementación:

应该调用 validateInput 三次。
应该读取 state.user.flags。
应该触发 handleClick 内部函数。

Una vez que los detalles de implementación estén resueltos, la refactorización será dolorosa. Acabas de cambiar la estructura interna, pero las pruebas fallaron a gran escala. En lugar de proteger el código, estas pruebas lo congelan.

Las buenas pruebas tienen límites

Es mejor diseñar una prueba para responder solo una pregunta.

Si una prueba también afirma:

• Formato correcto
• Los permisos son correctos.
• La solicitud de red es correcta.
• La copia del brindis es correcta.
• El estado de la base de datos es correcto.

Cuando falla, es difícil saber cuál es el problema.

La IA es especialmente propensa a escribir pruebas tan “grandes y completas” porque quiere demostrar muchas cosas a la vez. TDD es todo lo contrario: una acción, un fracaso y una implementación.

Las buenas pruebas dificultan que las implementaciones hagan trampa

Si la prueba solo cubre una entrada que es demasiado específica, la IA puede escribir una implementación falsa que simplemente coincida.

Por ejemplo:

def slugify(text: str) -> str:
    return "hello-world"

La primera prueba le permitirá pasar, pero la segunda prueba eliminará la lógica real:

def test_slugify_handles_another_title():
    assert slugify("Test Driven Development") == "test-driven-development"

Por lo tanto, TDD no siempre escribe solo una prueba, sino que solo agrega una presión conductual en cada ronda. La presión aumenta gradualmente y el diseño crece gradualmente.

5. ¿Cómo evitará la IA el TDD?

Esta parte debe quedar clara porque la IA no respeta naturalmente las pruebas.

Su objetivo de optimización es simple: completar la tarea que acabas de mencionar. Si dice "dejar pasar la prueba", es posible que se realicen algunas acciones que los humanos no quieren.

El primer tipo: cambiar la prueba para que se ponga verde

Los más típicos:

• Cambie assert slugify("Hello World") == "hello-world" a la salida actual
• Eliminar afirmaciones fallidas
• Añade skip a la prueba.
• Cambiar afirmaciones estrictas por afirmaciones flexibles

Esto no es TDD, esto es apagar la luz roja.

El segundo tipo: escribir implementación de sobreajuste

Por ejemplo, la prueba tiene sólo una entrada:

def test_slugify_lowercases_and_uses_hyphen():
    assert slugify("Hello World") == "hello-world"

El modelo podría escribirse como:

def slugify(text: str) -> str:
    if text == "Hello World":
        return "hello-world"
    return text

No es necesario que lo regañes en este momento. Debe continuar agregando el siguiente comportamiento para que la implementación no pueda continuar codificada.

El tercer método: use simulacro para cubrir el límite real

A la IA le encantan las burlas. Los simulacros facilitan la redacción de pruebas y hacen desaparecer muchos problemas reales.

No es que no puedas burlarte, pero hay que preguntar:

¿De lo que me estoy burlando ahora es de una dependencia lenta, o es un límite que realmente quiero verificar?

Si desea verificar el análisis de devolución de llamada de pago pero simular la capa de análisis, la prueba no tendrá sentido.

6. Cuándo no utilizar TDD

TDD tiene valor, pero no todo vale la pena.

Escena inadecuada

• Puro ajuste visual
• guión único
• Demostración de exploración tecnológica.
• Prototipos cuyos requisitos no han sido claramente pensados
• El marco de prueba aún no ha creado un almacén.

En estos escenarios, busque primero la velocidad de exploración y no se deje frenar por el proceso.

Escena adecuada

• correcciones de errores
• Permisos, facturación, máquina de estados.
• Transformación de datos y manejo de límites.
• Módulos principales que se mantendrán durante mucho tiempo.
• Rutas de código que la IA modificará repetidamente

El criterio de valoración no es "si esta función es excelente o no", sino:

Si está mal, ¿son obvios los costos?

El costo es obvio, por lo que vale la pena escribir la prueba primero.

7. Un método mental ejecutable

Si tuviera que darle a AI solo una frase, no diría:

请高质量实现这个功能。

Yo diría:

先写一个失败测试，运行它，确认失败原因符合预期。不要写实现，直到我说 go。

Esta frase es de mayor calidad porque no le pide al modelo que "se porte bien", sino que le pide que entre en un proceso que pueda comprobarse.

Un poco más completo:

每轮只处理一个行为。
RED：写一个失败测试并运行。
GREEN：写最小实现，不改测试。
REFACTOR：只在绿色状态下整理结构。
每轮报告测试文件、命令、失败原因、通过结果。

Este es el núcleo de TDD en la era de la IA.

No supersticioso sobre pruebas o procesos, sino sobre tener evidencia para cada paso.

Cierre

Lo que más necesita la programación de IA no es más código, sino comentarios más breves.

Este es el valor de TDD: convierte "Pensé que debería ser correcto" en "Aquí hubo un error y luego se puso verde". El cambio es pequeño, pero bastante real.

Si sólo recuerdas una frase, recuerda esto:

No permita que la IA entregue el código directamente. Primero déjelo emitir una luz roja y luego deje que la luz roja se vuelva verde.

La próxima Guía Práctica convertirá este ritmo en un flujo de trabajo que se puede copiar directamente.

Recursos recomendados

TDD, AI agents and coding with Kent Beck

Un ingeniero pragmático entrevista a Kent Beck. La atención se centra en la retroalimentación de pequeños pasos, la protección de pruebas y la disciplina de ingeniería en la programación de IA.YouTube