1382. Identidad de la lección
1383. Objetivo de aprendizaje
Al terminar esta lección, podrás producir una verificación automatizada repetible que prepare un estado conocido, ejecute una acción significativa, observe un resultado y demuestre que la verificación falla cuando el comportamiento esperado se rompe deliberadamente.
1384. Por qué importa
Una verificación de producción solo resulta útil si otra persona puede ejecutarla e interpretar su resultado. Un test verde con una preparación ambigua o afirmaciones débiles genera una confianza falsa; un test rojo sin intención clara genera ruido durante la depuración. Esta verificación convierte un criterio de aceptación en evidencia ejecutable. También ofrece al colaborador de IA una tarea delimitada que puede implementar y revisar, en lugar de pedirle código de test sin validación.
1385. Conocimientos previos
Debes poder:
- Expresar un criterio de aceptación observable.
- Distinguir un fallo significativo de un fallo del ejecutor o de la preparación.
- Identificar el estado del juego y el resultado relevantes para un comportamiento pequeño.
- Ejecutar el comando de verificaciones automatizadas existente en el proyecto o su equivalente.
Esta lección continúa directamente Un test debe fallar por la razón correcta.
1386. Concepto central
Una verificación centrada en un resultado tiene cuatro partes deliberadas:
- Preparar un estado inicial conocido.
- Actuar una vez mediante el comportamiento que se quiere comprobar.
- Observar un resultado acotado y relevante para el jugador.
- Diagnosticar el resultado confirmando que un defecto deliberado produce el fallo esperado.
La verificación no es una transcripción de los detalles de implementación. Es una afirmación repetible sobre el comportamiento.
1387. Modelo mental
Usa la ficha P-A-O-D:
| Parte | Pregunta | Evidencia que debes registrar |
|---|---|---|
| Preparar | ¿Qué debe ser cierto antes de la acción? | Estado, fixture o valores iniciales |
| Actuar | ¿Qué única acción activa el comportamiento? | Entrada, comando o frontera del comportamiento |
| Observar | ¿Qué resultado visible o accesible debería producirse? | Una afirmación sobre el resultado previsto |
| Diagnosticar | ¿Qué sucede cuando el comportamiento se vuelve incorrecto a propósito? | Afirmación fallida y mensaje de error esperado |
Una secuencia reutilizable es:
ESTADO CONOCIDO → UNA ACCIÓN → UN RESULTADO → ROTURA DELIBERADA → FALLO ESPERADO → RESTAURAR
Mantén la verificación enfocada. Si necesita varias acciones o afirmaciones no relacionadas, separa el comportamiento o aclara primero el criterio de aceptación antes de añadir código.
1388. Ejemplo concreto
Supón que una regla sencilla del juego dice: cuando el jugador recoge un objeto de suministros válido, la cantidad del inventario aumenta en uno.
La verificación puede planearse así:
- Preparar: Crear un jugador con el inventario vacío y colocar un objeto válido dentro de la distancia de recogida.
- Actuar: Activar una vez la acción de recoger.
- Observar: Afirmar que la cantidad del inventario es
1. - Diagnosticar: Cambiar temporalmente la regla de recogida para que no añada el objeto. Ejecutar la verificación y confirmar que el fallo identifica la afirmación de cantidad esperada, no un fixture ausente, un error de sintaxis o un tiempo de espera ajeno.
- Restaurar: Devolver la regla a su comportamiento previsto y ejecutar de nuevo la verificación para confirmar que pasa.
La afirmación trata sobre el resultado del inventario. No necesita comprobar cada llamada a un método privado, cada animación o cada variable interna, salvo que esos detalles formen parte del contrato que se está verificando.
1389. Flujo de trabajo nativo de IA
Usa la IA para acelerar la implementación y la inspección, no para decidir si la verificación demuestra el comportamiento.
- Completa la ficha P-A-O-D antes de pedir código.
- Proporciona al colaborador de IA el criterio de aceptación, los archivos o símbolos relevantes, el comando de tests existente y estas restricciones: un comportamiento, una acción y un resultado principal.
- Pídele que proponga la verificación más pequeña e identifique sus supuestos sobre fixtures, tiempos o estado de ejecución.
- Inspecciona la propuesta comparándola con la ficha. Rechaza las afirmaciones que solo confirmen llamadas a métodos, la finalización del ejecutor o detalles incidentales de implementación.
- Pide al colaborador que explique qué defecto deliberado haría fallar la afirmación y qué fallo debería aparecer.
- Aplica o edita la implementación mediante el flujo normal del proyecto y ejecuta tú la verificación.
Un prompt útil es:
Implementa una verificación automatizada para este criterio de aceptación: “[resultado observable]”. Prepara este estado inicial: “[estado]”. Ejecuta solo esta acción: “[acción]”. Observa solo este resultado principal: “[resultado]”. Usa las convenciones de tests existentes del proyecto. Primero enumera tus supuestos y los archivos que cambiarías. Después muestra cómo un defecto deliberado produciría un fallo de afirmación esperado. No añadas cobertura no relacionada.
La responsabilidad de confirmar que el fallo deliberado tiene sentido y que la verificación restaurada pasa sigue siendo del desarrollador.
1390. Error común
El error común es tomar la finalización correcta del ejecutor como prueba de que el comportamiento funciona. Una verificación puede pasar sin alcanzar la acción prevista, afirmando solo que existe un objeto o usando silenciosamente un fixture que no representa el estado declarado. El error contrario es añadir tantas afirmaciones y rutas de preparación que la verificación se vuelva difícil de diagnosticar. Sigue el recorrido Preparar, Actuar, Observar y Diagnosticar.
1391. Práctica guiada
Construye una verificación para un comportamiento pequeño que ya exista en el proyecto o en el área de práctica de la lección.
Paso 1: Elegir un resultado
Escribe una frase con este formato:
Dado [estado inicial conocido], cuando [una acción], entonces [un resultado observable].
Rechaza la frase si el resultado es solo “no ocurrió ningún error”, si incluye varios resultados no relacionados o si no puede observarse mediante una frontera de test disponible en el proyecto.
Paso 2: Completar la ficha
Registra:
- El estado inicial exacto.
- La única acción que cambia o evalúa el estado.
- La afirmación principal.
- El mensaje de fallo probable.
- Un defecto deliberado que debería hacer fallar la afirmación.
Toma una decisión de diseño: elige la frontera más estrecha que aún demuestre el resultado relevante para el jugador. Por ejemplo, si el criterio trata sobre el inventario, es preferible comprobar la cantidad final del inventario que comprobar una llamada a un helper privado.
Paso 3: Implementar la verificación mínima
Usa la estructura y las convenciones de nombres existentes. Mantén la preparación local, salvo que el proyecto ya ofrezca un fixture estable. No añadas esperas, reintentos o afirmaciones adicionales solo para aparentar que una verificación inestable es fiable. Si el comportamiento no puede aislarse sin crear infraestructura considerable, documenta esa limitación en lugar de ocultarla con una preparación excesivamente amplia.
Paso 4: Ejecutar la verificación en su entorno previsto
Registra el resultado inicial y confirma que la verificación llega hasta su afirmación. Si falla durante la preparación, detente y corrige la preparación antes de diagnosticar el comportamiento. Si pasa, continúa con la fase de fallo deliberado.
Paso 5: Demostrar el fallo deliberado
Introduce temporalmente un defecto controlado en el comportamiento bajo prueba, por ejemplo, impidiendo el cambio de estado esperado. Ejecuta solo esta verificación. Registra:
- El comando o destino de test utilizado.
- La afirmación que falló.
- El valor esperado y el valor observado.
- Por qué el fallo demuestra que la verificación detecta el defecto del comportamiento.
No conserves el defecto deliberado. Restaura la implementación y ejecuta de nuevo la verificación.
1392. Validación / evidencia
El trabajo está completo cuando puedes señalar todo lo siguiente:
- Un criterio de aceptación expresado como estado conocido, una acción y un resultado observable.
- Una verificación cuya preparación, acción y afirmación principal se pueden localizar sin adivinar.
- Una ejecución exitosa después de restaurar el comportamiento previsto.
- Una ejecución con fallo deliberado en la que la afirmación esperada falla por el defecto del comportamiento, no por una preparación ausente, un error de sintaxis o un problema ajeno del entorno.
- Un diagnóstico breve que explique por qué la verificación es repetible y qué queda intencionadamente fuera de su alcance.
Si la verificación no puede producir evidencia de fallo deliberado, no la marques como terminada. Identifica primero si el problema está en el criterio de aceptación, la preparación, la frontera de acción, la observación o el entorno de tests.
1393. Puntos clave
- Una verificación de producción convierte un criterio de aceptación observable en evidencia repetible.
- Preparar, Actuar, Observar y Diagnosticar son responsabilidades distintas; confundirlas dificulta interpretar los fallos.
- Un resultado enfocado suele aportar más valor que una cobertura amplia y ambigua.
- Romper deliberadamente el comportamiento confirma que la verificación puede detectar el defecto que afirma cubrir.
- La IA puede proponer e implementar la verificación, pero el desarrollador debe revisar la afirmación y diagnosticar el fallo.
1394. Próxima lección
Continúa con 3.16 — Debugging.
1395. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué secuencia representa mejor una verificación de producción enfocada?
Mostrar respuesta y explicación
Respuesta: Preparar, actuar, observar, diagnosticar
Por qué: Una verificación enfocada prepara deliberadamente el estado inicial, ejecuta el comportamiento, observa el resultado previsto y diagnostica si un defecto deliberado produce el fallo esperado.
¿Por qué se debe introducir un defecto deliberado después de que la verificación pase inicialmente?
Mostrar respuesta y explicación
Respuesta: Para verificar que la comprobación puede detectar el defecto de comportamiento que afirma cubrir
Por qué: Un fallo deliberado demuestra que la verificación responde al comportamiento previsto, en vez de limitarse a completar la preparación o el ejecutor de tests.
¿Qué observación encaja mejor con el criterio de aceptación del inventario del ejemplo?
Mostrar respuesta y explicación
Respuesta: La cantidad del inventario pasó a ser 1
Por qué: La cantidad del inventario es el resultado observable expresado por el criterio. Las llamadas internas, el estado de la animación y la finalización del ejecutor no prueban que el inventario haya cambiado correctamente.
¿Qué debes hacer si la verificación falla durante la preparación en lugar de hacerlo en su afirmación prevista?
Mostrar respuesta y explicación
Respuesta: Reparar o aclarar la preparación antes de diagnosticar el comportamiento
Por qué: Un fallo durante la preparación todavía no aporta evidencia sobre el comportamiento probado. Repara o aclara la preparación para que la verificación llegue a la afirmación prevista antes de diagnosticar el comportamiento.