Haz que una prueba falle por la razón correcta

2238. Identidad de la lección

Módulo

5.9 — Pruebas generadas por IA

Lección

Haz que una prueba falle por la razón correcta

Tipo académico

Laboratorio de depuración

Tipo de esquema

Práctica

Orden

2

Tiempo estimado

40–50 minutos

Este laboratorio continúa Pedir a la IA pruebas que expresen un contrato. Vas a desafiar una prueba generada introduciendo un defecto controlado, observarás el resultado y diagnosticarás si la prueba realmente protege el contrato.

2239. Objetivo de aprendizaje

Después de esta lección, podrás demostrar, diagnosticar y corregir una prueba engañosa o ineficaz mostrando que falla cuando se rompe el comportamiento previsto y que pasa cuando ese comportamiento se conserva.

2240. Por qué importa

Una prueba aprobada no es automáticamente una prueba útil. Puede pasar porque comprueba el valor equivocado, nunca alcanza la rama relevante o reproduce el mismo defecto que la implementación. La IA puede generar pruebas que parecen precisas y aun así producen una falsa sensación de seguridad. En un sistema de juego, eso puede dejar sin protección una regla de economía, un umbral de progresión o una respuesta de entrada. Provocar un fallo de forma deliberada revela si el contrato de la prueba es real.

2241. Conocimientos previos

Debes haber completado Pedir a la IA pruebas que expresen un contrato. Debes poder identificar el comportamiento previsto, los criterios de aceptación observables, la invariante, los límites y el oráculo de una regla pequeña del juego. También debes poder ejecutar el comando de pruebas del proyecto e inspeccionar el mensaje de fallo.

2242. Concepto central

El concepto central es la validez del fallo: una prueba es confiable solamente cuando falla porque se violó el contrato previsto, no por una configuración rota, una excepción ajena, un fixture incorrecto o una discrepancia entre la prueba y la implementación.

Usa dos cambios controlados:

1. Romper el comportamiento: introduce un defecto pequeño que viole el contrato. La prueba debe fallar con una aserción que señale esa violación.
2. Romper la prueba: modifica la prueba o su preparación para que deje de comprobar el contrato. Puede pasar, fallar por una causa ajena o dejar de recorrer la ruta objetivo.

El primer cambio demuestra detección. El segundo enseña a diagnosticar. Ambos son necesarios porque una prueba que falla no es necesariamente una buena prueba.

2243. Modelo mental

La cadena de validez del fallo

Una prueba útil debe producir esta secuencia:

Comportamiento correcto → pasa; violación controlada del contrato → falla de forma significativa; comportamiento corregido → pasa.

Si la secuencia no se cumple, deja de tratar el resultado como evidencia e inspecciona la prueba.

2244. Ejemplo concreto

Supón que una regla de recompensa del refugio dice: cuando una incursión termina con éxito, el jugador recibe la recompensa base más el bono aprobado; una incursión fallida no recibe el bono de éxito.

El contrato para una incursión exitosa con recompensa base de 100 y bono de 25 establece un resultado de 125. Una prueba generada por IA podría contener esta aserción:

expect(resolveReward({ success: true, base: 100, bonus: 25 })).toBe(125);

Para comprobar la validez del fallo, modifica temporalmente la implementación para que devuelva solamente base. Una prueba válida debe fallar mostrando 125 como esperado y 100 como resultado real. Ese fallo está conectado con el contrato.

Ahora considera dos alternativas engañosas:

• La prueba llama a resolveReward({ success: false, base: 100, bonus: 25 }) pero sigue esperando 125. Puede estar comprobando una regla distinta de la que se está analizando.
• La prueba calcula el esperado con la misma función que usa la implementación: toBe(calculateReward(input)). Si ambas contienen la omisión del bono, la prueba puede pasar aunque el contrato esté roto.

La prueba no se valida por su apariencia ni por un resultado verde. Se valida por su comportamiento frente a un defecto controlado y relevante para el contrato.

2245. Flujo de trabajo con IA

Usa la IA como una herramienta para desafiar y diagnosticar la prueba, no como la autoridad que decide si es válida.

1. Proporciona a la IA el contrato, la prueba, la implementación relevante y el defecto controlado exacto que introdujiste.
2. Pídele que prediga el fallo esperado y que indique qué aserción debería fallar.
3. Ejecuta la prueba tú mismo y compara la salida real con la predicción.
4. Si el resultado es distinto, pide a la IA varias explicaciones posibles y luego inspecciona por tu cuenta la preparación, la ruta de ejecución, el oráculo y la implementación.
5. Pide una corrección solamente después de poder explicar por qué la prueba actual es engañosa.
6. Aplica o rechaza la sugerencia según el contrato y repite la secuencia con el defecto controlado.

No preguntes solamente a la IA: «¿Esta prueba parece correcta?». Formula preguntas que exijan evidencia: «¿Qué violación del contrato haría fallar esta prueba?», «¿Qué defecto podría no detectar?» y «¿Qué línea demuestra que se ejecutó el comportamiento objetivo?».

2246. Error común

El error común es tomar cualquier prueba roja como evidencia de que la prueba funciona. Puede fallar porque el fixture está mal formado, un mock no está configurado, una importación está rota o la aserción comprueba un detalle incidental de la implementación. Antes de interpretar el fallo, identifica la ruta ejecutada, el valor esperado y la cláusula del contrato que representa.

Otro error es cambiar varias cosas a la vez. Si modificas la implementación, el fixture y la aserción simultáneamente, no podrás saber cuál cambio produjo el resultado. Haz un solo cambio controlado cada vez.

2247. Práctica guiada

Usa una prueba pequeña generada o revisada en la lección anterior. Elige un contrato con un resultado observable claro. No uses un escenario amplio de extremo a extremo para este laboratorio.

Parte A — Establecer la línea base

1. Escribe el contrato en una frase, incluyendo la condición de entrada y el resultado observable esperado.
2. Ejecuta la prueba sin cambios.
3. Registra el resultado, la aserción evaluada y la función o ruta que la prueba pretende recorrer.
4. Identifica el origen del valor esperado. Debe provenir del contrato o de un ejemplo independiente, no de la implementación bajo prueba.

Parte B — Introducir un defecto previsto

1. Haz un cambio temporal en la implementación que viole el contrato. Por ejemplo, omite un componente obligatorio de la recompensa, usa una comparación incorrecta en un umbral o devuelve el estado anterior a la actualización.
2. Ejecuta solamente la prueba objetivo.
3. Guarda el mensaje de fallo e identifica la aserción que falló.
4. Decide si el fallo representa directamente la violación del contrato. Si no, inspecciona el alcance, el oráculo y la preparación antes de modificar la prueba.
5. Restaura la implementación y confirma que la prueba vuelve a pasar.

Parte C — Desafiar la prueba

Elige un desafío y hazlo temporalmente:

• Modifica el fixture para impedir que se alcance la rama objetivo.
• Sustituye el esperado independiente por un valor calculado por la implementación.
• Cambia la entrada para probar un caso vecino en vez del contrato declarado.
• Elimina o debilita la aserción manteniendo ejecutable la prueba.

Ejecuta la prueba y clasifica el resultado como fallo significativo, falso aprobado o fallo no relacionado. Explica la clasificación en una o dos frases. Después corrige la prueba y repite la secuencia línea base → defecto controlado → reparación.

Durante el laboratorio, usa la IA para generar hipótesis sobre el resultado, pero verifica cada hipótesis leyendo la prueba y examinando la salida del ejecutor.

2248. Validación / evidencia

2249. Ideas clave

• Una prueba útil debe fallar cuando se rompe el comportamiento descrito por su contrato.
• La validez del fallo depende del alcance, de un oráculo independiente y de un defecto relevante para el contrato.
• Una prueba roja puede indicar una preparación rota, no una implementación rota.
• Los defectos controlados permiten comprobar si una prueba realmente ofrece protección.
• La IA puede sugerir diagnósticos, pero debes verificarlos contra el contrato y la evidencia del ejecutor.

2250. Comprobación de conocimientos

2251. Siguiente lección

Continúa con 5.10 — Pipeline de arte con IA.

2252. Comprobación