1369. Identidad de la lección
1370. Objetivo de aprendizaje
Al terminar esta lección, podrás redactar un criterio de aceptación y una condición de fallo significativos que conecten una verificación automatizada con un riesgo concreto del juego, y después comprobar que el resultado esperado y la configuración del test son válidos.
1371. Por qué importa
Un test que pasa solo es útil si comprueba el comportamiento que querías proteger. Un test que falla solo es útil si el fallo apunta a ese comportamiento y no a una configuración rota, una dependencia ajena o un detalle demasiado específico de la implementación. Esta distinción permite evaluar los tests como evidencia, en lugar de tratar su estado como un veredicto. También proporciona una pregunta precisa para revisar lo que proponga o modifique la IA: ¿qué riesgo expone esta verificación, qué resultado debería observarse y la configuración es lo bastante válida para que el fallo tenga significado?
1372. Conocimientos previos
Ya debes poder revisar un conjunto de cambios asistido por IA, comparar los límites de una tarea con el diff real e identificar si un cambio está respaldado por evidencia. Esta lección se apoya en 3.14 L2 — Review an AI-assisted change set. No necesitas un framework de testing específico; los ejemplos usan criterios de aceptación y pseudocódigo en lenguaje común.
1373. Concepto central
Un test significativo tiene tres partes conectadas:
- Intención: el riesgo o comportamiento que el test debe proteger.
- Criterio de aceptación: el resultado observable que cuenta como correcto.
- Significado del fallo: la conclusión concreta que se puede extraer razonablemente cuando la verificación falla.
Estas partes deben permanecer acopladas. Si el criterio no expresa el riesgo, el test puede pasar mientras el riesgo continúa presente. Si la condición de fallo depende de una configuración ajena, el test puede fallar sin aportar evidencia útil. Si el test depende de detalles privados de implementación, un refactor legítimo puede producir ruido.
Un criterio sólido es observable, delimitado y relevante para un resultado observable por el jugador o a nivel de sistema. Por ejemplo: “Cuando el jugador confirma una compra válida teniendo fondos suficientes, el objeto se añade al inventario y el saldo disminuye en el precio indicado”. Esto es más fuerte que “la función de compra funciona”, porque especifica qué debe observarse en el estado resultante.
Un fallo significativo también requiere una configuración válida. La configuración debe crear las precondiciones indicadas y permitir observar el resultado esperado. Si el objeto no tiene precio, el jugador no tiene fondos suficientes o el estado del inventario no puede observarse, el fallo puede describir la configuración y no el comportamiento de compra.
1374. Modelo mental
Usa la cadena Riesgo → Criterio → Significado del fallo y después realiza una comprobación del resultado y la configuración:
| Parte | Pregunta | Ejemplo |
|---|---|---|
| Riesgo | ¿Qué podría salir mal? | Una compra correcta podría no entregar el objeto y aun así cobrar al jugador. |
| Criterio | ¿Qué resultado observable demuestra que el comportamiento es aceptable? | El inventario contiene el objeto comprado y el saldo disminuye exactamente por su precio. |
| Significado del fallo | Si falla la verificación, ¿qué indica? | El resultado de la compra no coincide con el criterio de aceptación, siempre que la configuración del test sea válida. |
| Comprobación del resultado y la configuración | ¿Se puede observar el resultado esperado y se cumplen las precondiciones? | El objeto tiene un precio definido, el jugador tiene fondos suficientes y el inventario y el saldo pueden inspeccionarse después de confirmar. |
Antes de confiar en un test, recorre la cadena en ambos sentidos. Empieza por el riesgo y comprueba si el criterio lo cubre. Después empieza por el fallo y comprueba si el resultado aísla ese riesgo. Por último, verifica que la configuración establece las precondiciones escritas y que el resultado esperado puede observarse. Si una conexión o una comprobación de validez es débil, el test necesita una revisión.
1375. Ejemplo concreto
Considera una interacción de comercio dentro de un juego. El riesgo no es simplemente “el código de compra puede tener un bug”. El riesgo relevante es que los recursos del jugador y su inventario queden en estados incompatibles.
Una verificación débil podría comprobar solamente que purchase() devuelve true. Puede pasar aunque el objeto nunca se añada o aunque el saldo no se reduzca. Además, aporta poca información sobre el resultado que percibe el jugador.
Un criterio de aceptación más sólido sería:
Dado un objeto válido y saldo suficiente, confirmar la compra añade exactamente una unidad de ese objeto al inventario y reduce el saldo exactamente por el precio indicado.
Una condición de fallo correspondiente sería:
Cuando se cumplen esas precondiciones, la verificación falla si el número de unidades del objeto no aumenta exactamente en uno, si el saldo no disminuye exactamente por el precio indicado o si una sola confirmación produce algún efecto duplicado en el inventario o en el saldo.
Cada resultado se comprueba de forma independiente. La verificación falla si falta cualquiera de los cambios de estado requeridos o si alguno es incorrecto; no hace falta que un resultado sea erróneo para que otro pueda provocar el fallo. La señal de éxito solo debe comprobarse por separado si forma parte del contrato público.
Antes de interpretar ese fallo, comprueba la configuración: el objeto debe tener un precio definido, el jugador debe tener saldo suficiente y el inventario y el saldo deben poder observarse después de la acción. Si falta una de esas condiciones, el test podría estar informando de una configuración inválida y no de una transacción defectuosa.
El significado del fallo ya es específico: el resultado de la transacción no cumple el contrato definido cuando la configuración es válida. Eso no demuestra automáticamente qué línea de código está equivocada. Un fallo identifica una expectativa incumplida; el diagnóstico todavía exige revisar la configuración, la ruta de ejecución y el estado observado.
1376. Error común
El error más común es equiparar “el test falló” con “la funcionalidad está rota”. Un test puede fallar porque el fixture es inválido, la expectativa está desactualizada, el entorno no está disponible o la verificación está acoplada a un detalle de implementación que cambió sin alterar el comportamiento previsto. Antes de registrar un defecto, comprueba que la configuración representa la precondición escrita, que el resultado esperado es observable y que la aserción expresa el criterio de aceptación, no un detalle incidental.
Otro error es escribir una aserción demasiado amplia, como “la transacción tiene éxito”. Las aserciones amplias ocultan fallos parciales. Nombra por separado cada cambio de estado que importa y define una condición de fallo independiente para cada uno, incluido lo que no debe ocurrir, como entregar recompensas duplicadas o descontar una cantidad incorrecta de recursos.
1377. Práctica guiada
Redacta la especificación de una verificación para este escenario:
Un jugador intenta reclamar una recompensa después de cumplir la condición requerida. La recompensa debe concederse una sola vez, y volver a reclamarla no debe crear un duplicado.
Completa estos pasos:
- Expresa un riesgo concreto en una frase. No nombres una función ni un archivo como riesgo.
- Escribe un criterio de aceptación usando el estado observable del juego.
- Escribe una condición de fallo que diferencie un problema real del producto de un problema de configuración.
- Identifica un detalle de implementación que la verificación no debe comprobar mediante una aserción.
- Decide si el resultado esperado puede observarse y si la configuración establece la precondición requerida. Explica qué evidencia demostraría que ambos son válidos.
Usa esta plantilla:
Riesgo:
Criterio de aceptación:
Condición de fallo:
Validez de la configuración y resultado observable:
Detalle de implementación que no se debe comprobar:
Una respuesta sólida podría indicar que el riesgo es entregar la recompensa dos veces, que el primer reclamo válido aumenta el contador de recompensas en uno y que un segundo reclamo deja el contador sin cambios. También debería declarar la precondición de que el jugador cumplió el requisito, identificar cómo puede observarse el contador de recompensas y explicar que la ausencia del requisito o de un estado de recompensa observable invalidaría la configuración. No copies este ejemplo sin adaptar la recompensa y el estado que se comprueban.
1378. Validación / evidencia
Tu evidencia es una especificación completa que otro desarrollador podría convertir en una verificación automatizada sin tener que adivinar el comportamiento esperado. Comprueba que incluye:
- Un riesgo expresado como un resultado incorrecto posible.
- Un criterio de aceptación expresado mediante un estado o comportamiento observable.
- Una condición de fallo que nombre de forma independiente cada expectativa incumplida.
- Una precondición o condición de validez de la configuración.
- Una explicación de cómo se observará el resultado esperado.
- Ninguna aserción que dependa únicamente de un nombre de método privado, un orden de llamadas u otro detalle incidental de implementación.
Si no puedes explicar qué confirma o descarta un fallo, o no puedes demostrar que la configuración crea la precondición indicada y expone el resultado esperado, revisa el criterio o la configuración antes de escribir código de test.
1379. Puntos clave
- Un test solo aporta evidencia cuando su intención está conectada con un riesgo específico.
- Un criterio de aceptación debe describir un resultado observable y delimitado.
- Cada resultado contractual debe tener una condición de fallo independiente.
- Un fallo identifica una expectativa incumplida; no identifica automáticamente el defecto.
- Una configuración válida debe establecer las precondiciones y exponer el resultado que se comprueba.
- Conviene afirmar comportamientos y resultados, no detalles incidentales de implementación.
1380. Siguiente lección
Continúa con Crear una verificación centrada en resultados.
1381. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué afirmación describe mejor un criterio de aceptación significativo?
Mostrar respuesta y explicación
Respuesta: Describe un resultado observable que demuestra el comportamiento previsto
Por qué: Un criterio de aceptación debe expresar un resultado observable y delimitado. Los nombres de métodos privados y la finalización del ejecutor no demuestran que ocurriera el comportamiento previsto.
Un test de compra falla porque su fixture crea un objeto sin precio, aunque la regla de compra es correcta. ¿Qué debe comprobarse primero?
Mostrar respuesta y explicación
Respuesta: Si la configuración cumple las precondiciones escritas
Por qué: Un fallo solo tiene un significado útil cuando la configuración representa las precondiciones indicadas. Un fixture inválido puede producir un fallo de configuración, no evidencia de una regla de compra defectuosa.
¿Qué aserción está más directamente conectada con el riesgo de entregar una recompensa duplicada?
Mostrar respuesta y explicación
Respuesta: Después de un reclamo válido y otro repetido, el contador de recompensas aumenta una sola vez
Por qué: El contador de recompensas es un resultado observable directamente relacionado con la entrega duplicada. Los conteos internos de llamadas y los nombres de clases pueden cambiar sin alterar el contrato visible para el jugador.
¿Qué demuestra de forma más directa una aserción fallida?
Mostrar respuesta y explicación
Respuesta: Que no se cumplió una condición esperada, suponiendo que la configuración era válida
Por qué: Una aserción fallida demuestra que el resultado observado no cumplió la expectativa, siempre que la configuración del test fuera válida. Todavía se necesita un diagnóstico para localizar la causa.