Prompt de tres capas para generar tests confiables

Escribir tests con IA suena tentador, pero pedir "escribe test para esta función" produce ruido sintácticamente perfecto que no prueba nada. Aquí aprendes a construir un prompt de tres capas que convierte a la IA en un ejecutor de tus decisiones, no en un inventor de comportamientos. Es material clave para desarrolladores que quieren tests confiables y auditables.

La premisa es directa: un prompt vago le delega a la IA una decisión que es tuya. Hoy le devuelves esa decisión a su dueño y usas la IA solo para ejecutar lo que tú ya pensaste.

Por qué un prompt vago para tests genera ruido

Cuando le dices a la IA "escribe test para esta función" sin contexto, ella tiende a inyectar datos estáticos y perezosos. Te pone un monto de 100 o una moneda dólar y produce lo que en la clase llaman un test decorativo: se ve bien en el repositorio, pasa, pero no presiona el código en absoluto.

Y aquí viene lo interesante. En un sistema de pagos la lógica no falla con 100 dólares. Falla cuando inyectas un monto en el límite exacto del céntimo, cuando envías divisas con caracteres extraños o cuando intentas procesar un valor negativo [4:30].

¿Qué es un test decorativo? Es un test que pasa pero no verifica nada real. Usa datos genéricos como un monto de 100 y nunca golpea los bordes donde el código realmente se rompe.

Cómo funciona el prompt de tres capas para tests

La estructura es simple: tres capas y cada una responde una pregunta distinta [0:26]. Qué hace el sistema, dónde puede romperse y qué fórmula debe tener el test para que sea auditable de un vistazo.

Qué incluye cada capa del prompt

Cada capa cumple una función específica y no se mezclan entre sí:

1. Sistema bajo prueba: describes exactamente qué hace la función, sus firmas, los contratos y sus dependencias. El objetivo es dar contexto duro para que la IA no alucine comportamientos que no existen [1:03].
2. Modos de falla: pegas directamente en el prompt las clases de equivalencia y los casos límite de tu catálogo. Aquí inyectas el cerebro de la operación y fuerzas a la IA a salir del happy path [1:31].
3. Forma del test: exiges un test por clase, con fixtures ricos y una estructura estandarizada. Si la salida no es legible, no es fácil de auditar [2:04].

La capa dos es donde vive tu conocimiento del negocio. Somos nosotros quienes sabemos cómo debe comportarse el sistema, así que forzamos a la IA a golpear los bordes en lugar de quedarse en el camino feliz.

Qué es la estructura triple A en un test

A la tercera capa siempre le exiges la estructura triple A: arrange, act y assert. Ese es el esqueleto innegociable de un buen test [2:37].

• Arrange o preparar: configuras el escenario inicial con los datos de entrada, los fixtures y el estado. Por ejemplo, creas un usuario, inyectas un balance o generas un token de sesión [2:47].
• Act o actuar: ejecutas la acción bajo prueba, pero solo una acción. Por ejemplo, llamas al endpoint con un modo negativo [3:04].
• Assert o afirmar: verificas el resultado. Por ejemplo, esperas una respuesta 400 Bad Request con un mensaje de error específico [3:15].

Pedir esta estructura explícitamente hace que los tests sean comparables entre sí. Un test que mezcla 10 actions y 15 asserts es imposible de revisar [3:34].

¿Para qué sirve la estructura triple A? Estandariza cada test en tres bloques (preparar, actuar, afirmar) para que puedas auditarlo de un vistazo y compararlo con otros tests.

Cómo cerrar modos de falla pendientes antes de generar tests

Antes de escribir los tests hay que cerrar los modos de falla que quedaron pendientes de decisión. La idea es tomar la lógica de negocio real y especificar, para cada caso, cuál es el comportamiento correcto.

En la clase quedaron dos ejemplos claros:

• Pérdida de precisión con float: si entra un float, Python puede introducir decimales basura y el monto cobrado queda mal. La decisión humana fue que parse_amount debe rechazar entradas float con AmountError [5:38].
• Monto en cero: un monto de 0.00 no cobra comisión, pero 0.01 ya cobra 0.30 dólares de comisión mínima. La decisión humana fue que los montos de cobro en cero son inválidos y validate_amount con decimal cero debe fallar con AmountError [5:04].

El prompt aquí es explícito: no escribas tests todavía, no cambies código de producción, cierra exactamente estos modos pendientes y no otros [5:26]. Cada decisión humana se convierte en un contrato verificable con la misma estructura que ya tenían los modos cerrados.

Qué significa que fallen tests recién generados

Al correr el prompt de tres capas se generaron los tests con la estructura triple A. La instrucción fue clara: usar solo modos de falla con estado de contrato confirmado y listar al final cualquier modo pendiente como pregunta abierta [7:22].

Un detalle técnico: en la iteración anterior se usó pytest, pero esta vez se especificó unittest como framework [8:20]. Al ejecutar la suite el resultado fue revelador.

¿Es malo que fallen tests recién generados? No siempre. Si los tests están basados en contratos oficiales y fallan, significa que encontraron bugs reales en el código, no errores en los tests.

De 29 tests, fallaron cinco [9:04]. Y eso es una buena señal, porque el prompt no solo generó tests: encontró bugs reales. Los tests estaban basados en los contratos confirmados, así que el problema estaba en el código, no en la prueba.

Cómo arreglar el código sin tocar los tests

Aquí entra una lógica parecida al test driven development. Como los tests ya definen lo que debe pasar, ahora hay que ajustar el código para que cumpla el contrato.

El prompt de corrección tiene reglas estrictas [10:12]:

• No cambies tests, no cambies el failures mode y no agregues dependencias.
• Para cada test fallido, identifica el ID del modo de falla que lo cubre.
• Si el test representa un contrato confirmado y es correcto, ajusta el código con el cambio mínimo.
• Si el test no está alineado con un contrato confirmado, no cambies el código para satisfacerlo, explícalo.

Tras correr ese prompt, la IA arregló el código, dejó un análisis de qué modo de falla usó para corregir cada parte y no tocó ningún test. Al ejecutar de nuevo, los 29 tests pasaron [11:10].

Pero cuidado con la falsa tranquilidad. Que un test pase no prueba nada por sí solo: puede estar en verde porque tu código es correcto o porque tu test no verifica nada. Distinguir entre esos dos casos requiere un oráculo, no un puntaje inventado por la IA.

¿Ya probaste estructurar tus prompts de test por capas? Cuéntame en los comentarios qué bugs reales te ayudó a descubrir.