Pide a la IA pruebas que expresen un contrato

2224. Identidad de la lección

Módulo

5.9 — Pruebas generadas por IA

Lección

Pide a la IA pruebas que expresen un contrato

Tipo académico

Flujo de trabajo

Tipo de esquema

mixto

Orden

1

Tiempo estimado

30–40 minutos, incluida la práctica

2225. Objetivo de aprendizaje

Al terminar esta lección, podrás producir y editar un plan de pruebas enfocado para un sistema, describiendo su comportamiento, criterios de aceptación, invariantes, límites, resultados esperados y riesgos de regresión.

2226. Por qué importa

Una prueba generada solo sirve si comprueba un comportamiento que el juego realmente promete. Si la petición a la IA describe únicamente la implementación, el resultado puede repetir esa implementación en lugar de proteger el contrato observable para el jugador. Los criterios de aceptación hacen que el contrato sea lo bastante preciso para evaluarlo: expresan las condiciones observables que deben cumplirse para considerar correcto el comportamiento. Un plan de pruebas enfocado te da una base para aceptar, editar o rechazar las pruebas generadas. También conecta el análisis de causa raíz y riesgo de regresión de la lección anterior con una tarea concreta de verificación.

2227. Conocimientos previos

Debes poder:

• describir el comportamiento previsto de un sistema y su resultado observable;
• distinguir una observación de una hipótesis sobre la causa raíz;
• identificar quién es responsable y qué riesgo de regresión existe, como se trabajó en 5.8 — Encontrar causa raíz, responsabilidad y riesgo de regresión;
• leer la implementación o interfaz relevante con suficiente precisión para nombrar entradas, cambios de estado y salidas.

2228. Concepto central

Una prueba expresa un contrato: bajo una condición definida, el sistema debe producir un resultado observable y conservar cualquier invariante indicada. Los criterios de aceptación son las condiciones explícitas y observables que permiten decidir si ese contrato se cumple. Deben describir lo que tiene que ser cierto desde la perspectiva del sistema o del jugador, no solo qué función interna o rama de código se ejecutó.

Para un sistema, registra cinco elementos y conviértelos en criterios de aceptación:

1. Comportamiento: qué debe hacer el sistema.
2. Entradas y estado: qué datos o condiciones permiten observarlo.
3. Invariante: qué debe seguir siendo cierto antes y después de la operación.
4. Límite: el caso vacío, inválido, extremo, umbral o transición donde puede cambiar el comportamiento.
5. Oráculo: la evidencia que permite decidir si la prueba pasa o falla.

Un criterio de aceptación útil contiene una condición definida y un resultado esperado observable. Por ejemplo: “Cuando el jugador tiene exactamente la moneda suficiente, una compra exitosa concede el objeto y reduce la moneda exactamente por el coste indicado”. “La compra funciona” es demasiado impreciso porque no identifica la evidencia necesaria para aceptarla.

Un plan está enfocado cuando cada caso protege un contrato distinto, en vez de acumular ejemplos casi iguales.

2229. Modelo mental

Escalera de contrato a prueba

Los criterios de aceptación conectan el contrato con una prueba mediante esta escalera:

Usa la escalera como lista de comprobación, no como un sistema para clasificar los casos. Cada caso debe indicar su intención o el ID del criterio de aceptación, las precondiciones y el estado inicial, la acción y el oráculo observable. Después registra por separado si cubre un límite y qué riesgo de regresión aborda. Pide a la IA que proponga casos solo cuando los criterios sean explícitos. Si un caso no está respaldado por un criterio o una intención, márcalo para eliminarlo o aclararlo; si un criterio no tiene caso, registra la brecha de cobertura.

2230. Ejemplo concreto

Supón que el sistema revisado es una operación para reclamar una recompensa. Su contrato es el siguiente:

• Si la recompensa está disponible y el jugador cumple el requisito, se concede una sola vez.
• Un intento fallido no elimina moneda ni progreso.
• Repetir un reclamo exitoso no concede la recompensa dos veces.

Los criterios de aceptación correspondientes son:

• Dada una recompensa disponible y un jugador que cumple el requisito, cuando la reclama, la recompensa se concede y el reclamo queda registrado.
• Dada una recompensa no disponible o un requisito incumplido, cuando el jugador reclama, no se concede la recompensa y el progreso y la moneda existentes permanecen sin cambios.
• Dado un reclamo ya realizado con éxito, cuando el jugador vuelve a reclamarlo, no se concede una segunda recompensa.
• Dados el requisito exacto y un valor inferior en un punto, el sistema produce el resultado de éxito o fallo especificado sin violar la invariante correspondiente.

Un plan enfocado puede incluir estos casos:

1. Primer reclamo válido: la recompensa se concede, el reclamo queda registrado y el estado relevante cambia una sola vez.
2. Reclamo no válido: la recompensa no se concede y el progreso y la moneda existentes permanecen sin cambios.
3. Reclamo repetido: la segunda solicitud se rechaza o se trata como ya reclamada, sin duplicar la recompensa.
4. Límite del requisito: se prueba el valor exacto del requisito y un valor inferior.

Ahora cada caso puede relacionarse con un criterio de aceptación. Observa que “el método termina sin error” no basta. El oráculo debe comprobar el estado relevante para el juego y la invariante. La IA puede sugerir casos adicionales, pero solo conservas un caso cuando puedes nombrar el criterio y el contrato que protege.

2231. Flujo de trabajo nativo de IA

Usa la IA como asistente de diseño de pruebas, no como autoridad sobre el comportamiento esperado. Esta lección termina con un plan aprobado y basado en contratos. Define las precondiciones y el estado inicial de forma declarativa; la construcción ejecutable del entorno y los fixtures, la implementación, la ejecución y el diagnóstico corresponden a L2.

1. Prepara el contexto. Proporciona el nombre del sistema, su comportamiento público, criterios de aceptación, entradas y salidas relevantes, invariantes, límites y riesgo de regresión conocido. Excluye archivos ajenos y no pidas una suite para todo el proyecto.
2. Solicita un plan. Pide una tabla con nombre del caso, ID del criterio de aceptación, precondiciones y estado inicial, acción, oráculo observable, invariante conservada, cobertura de límites, riesgo de regresión y motivo de inclusión.
3. Cuestiona el borrador. Pregunta qué casos son duplicados, qué comprobaciones solo repetirían detalles de implementación, qué criterios de aceptación no tienen cobertura, qué límites faltan y qué resultados esperados no están respaldados por el contrato.
4. Edita para preservar la verdad. Corrige suposiciones, elimina casos especulativos, añade rutas de fallo que falten y haz que cada criterio de aceptación y oráculo sea observable y determinista. Si un resultado esperado no está especificado, regístralo como decisión de diseño pendiente en lugar de elegir la sugerencia de la IA.
5. Aprueba el artefacto de entrega. Selecciona y edita los casos respaldados por el contrato, comprueba que estén completos, relaciona cada uno con un criterio de aceptación y registra las brechas y sugerencias rechazadas.

Una petición útil es específica: “Deriva un plan de seis casos para estos criterios de aceptación del reclamo de recompensa. Separa casos normales, fallidos, repetidos y de límite. Para cada caso, indica el criterio que verifica, las precondiciones y el estado inicial, la acción, el oráculo observable, la invariante conservada, la cobertura de límites, el riesgo de regresión y el motivo de inclusión. No infieras comportamientos que no estén listados”.

2232. Error común

El error habitual es aceptar una suite grande porque parece exhaustiva, sin comprobar si sus casos se relacionan con criterios de aceptación explícitos. La cantidad no demuestra cobertura. Una prueba puede ser redundante, quedar acoplada a la implementación, ser no determinista o basarse en una expectativa inventada. Rechaza cualquier candidato cuyo criterio de aceptación, contrato, oráculo o motivo de inclusión no puedas explicar con claridad.

2233. Práctica guiada

Elige un sistema pequeño que ya hayas inspeccionado, como una compra, un reclamo de recompensa, un enfriamiento, una transferencia de inventario o una comprobación de progresión. No elijas el juego completo.

1. Escribe una frase sobre el comportamiento previsto.
2. Enumera las entradas y el estado inicial relevantes.
3. Escribe una invariante que deba conservarse durante la operación.
4. Identifica al menos dos límites, incluido un caso fallido o inválido.
5. Convierte el comportamiento, la invariante y los límites en criterios de aceptación explícitos. Asigna a cada criterio un ID breve, como AC-1 o AC-2.
6. Define un oráculo observable para cada criterio.
7. Pide a la IA un plan usando la escalera como lista de comprobación. Exige que cada caso incluya un ID de criterio de aceptación, precondiciones y estado inicial, acción y oráculo observable, además de indicar por separado la cobertura de límites y el riesgo de regresión.
8. Compara el plan de la IA con tu lista. Marca cada candidato como conservar, editar, eliminar o requiere decisión.
9. Selecciona entre cuatro y seis casos y redacta el plan final con tus propias palabras. Incluye en cada caso su ID de criterio de aceptación, precondiciones y estado inicial, acción, oráculo observable, si cubre un límite y qué riesgo de regresión aborda.

La decisión obligatoria es elegir qué caso generado por la IA rechazarías o editarías, y explicar si es redundante, no está respaldado, depende demasiado de la implementación, está incompleto o presenta otro riesgo. No aceptes el plan hasta que cada caso seleccionado esté completo y sea trazable a un criterio, y cada criterio importante tenga cobertura o una brecha registrada explícitamente.

2234. Validación / evidencia

2235. Puntos clave

• Una prueba protege un contrato, no solo una ruta de implementación.
• Los criterios de aceptación expresan las condiciones observables que hacen que un contrato pase o falle.
• Usa la escalera para comprobar que cada caso incluya intención, precondiciones y estado inicial, acción y oráculo; no la uses para asignar el caso a una sola capa.
• Registra la cobertura de límites y el riesgo de regresión por separado.
• Usa la IA para ampliar y cuestionar la intención de las pruebas; verifica tú cada resultado esperado.

2236. Siguiente lección

Siguiente: 5.9 L2 — Haz que una prueba falle por la razón correcta. Lleva contigo el plan de pruebas aprobado y basado en contratos. En L2 trabajarás la generación e implementación del código de prueba, la construcción ejecutable de fixtures y del entorno, la ejecución y el diagnóstico de fallos de aserción.

2237. Comprobación