Una marca verde no demuestra que la prueba sea correcta
Los agentes de IA escriben pruebas de extremo a extremo, pero un mensaje de éxito no demuestra que los datos se hayan guardado. Verifica el resultado por una vía independiente.
Edición traducida. Los identificadores técnicos permanecen en su forma original.
La prueba pulsa "Enviar". Aparece el mensaje "Guardado". La prueba comprueba ese mensaje y pasa. Tres semanas después, un usuario avisa de que sus ajustes nunca se guardaron. Es un ejemplo ilustrativo, no el relato de un incidente real.
Nada en esta historia es nuevo y nada requiere IA. Es la forma estándar en que se encuentran las pruebas de un extremo a otro: la comprobación observa la interfaz de usuario, y la interfaz de usuario es lo que se prueba. Cuando un agente de IA escribe las pruebas, el mismo modo de falla llega a escala industrial, porque el agente también aprende qué afirmar al observar la interfaz.
El problema del oráculo, en un párrafo
Cada prueba tiene dos mitades. La primera mitad hace algo. La segunda mitad decide si el resultado es correcto. Esa segunda mitad es el oráculo, y es la mitad que importa. Un oráculo débil comprueba la señal visible más cercana: un mensaje de confirmación, una ruleta que se detiene, un cambio de URL. Un oráculo fuerte verifica el resultado desde una dirección independiente: el registro en la base de datos, la respuesta de la API a la que llama la página, el estado después de una nueva recarga.
La propia guía de mejores prácticas de Playwright destaca el punto adyacente sobre las acciones: las pruebas deben verificar el comportamiento que el usuario final puede ver y evitar el acoplamiento con detalles de implementación como clases CSS. El mismo principio aplicado a las comprobaciones nos da la regla para la era de la IA. Afirmar el resultado que un usuario verificaría, a través de una ruta que el error no puede falsificar.
Por qué las pruebas escritas por IA derivan hacia oráculos débiles
Un agente que explora su aplicación y escribe pruebas aprende la aplicación desde su superficie. Hace clic, observa qué cambia y codifica exactamente eso: haga clic en esto, luego esto cambia. Un mensaje de confirmación es una señal conveniente y de apariencia determinista, así lo afirma el agente en el mensaje de confirmación. El agente no es descuidado. Simplemente no tiene acceso a tu intención, sólo a tus píxeles.
La espera automática de Playwright hace que esto parezca más seguro de lo que es. Las comprobaciones de capacidad de acción confirman que un elemento es visible, estable y recibe eventos antes de que llegue el clic. Las aserciones de reintento automático esperan la condición esperada. Ambos reducen las fallas relacionadas con la sincronización. Ninguno pregunta si la condición era la correcta. Una prueba puede ser perfectamente estable y completamente errónea.
Tres actualizaciones de Oracle que funcionan hoy
Recargar y leer. Después de guardar, navegue hacia atrás y hacia afuera, o vuelva a cargar y confirme que el valor todavía está ahí. Esto verifica la persistencia de la misma manera que un usuario notaría su ausencia.
Afirmar una capa hacia abajo. El dramaturgo puede esperar la respuesta de la red de la que depende la interfaz de usuario. Empareje la aserción de la interfaz de usuario con expect(response).toBeOK() en la llamada API que realmente guarda, o consulte la API directamente después del flujo de la interfaz de usuario y compare el valor almacenado.
Compruebe el efecto secundario fuera de banda. Para registrarse, haga valer en la bandeja de salida, el registro de auditoría o la lista de administradores, no en el banner de bienvenida. El banner está diseñado para aparecer; el registro existe sólo si el sistema funcionó.
La pregunta de repaso que lo cambia todo
Si permite que los agentes escriban pruebas y los humanos las revisen, dedique tiempo de revisión a una pregunta por prueba: ¿qué afirma esto? ¿Podría aprobarse mientras la función no funciona? Repasar el camino feliz es leer la prueba. Revisar el oráculo es probar la prueba.
Esta es también la forma honesta de utilizar una herramienta como AnyTest. Sus agentes exploran su aplicación desde una URL, crean pruebas de un extremo a otro y las dejan para su revisión. La superficie de revisión muestra cada paso y su resultado. Si se usa bien, esa revisión es donde ocurre la verificación de Oracle: no "el agente hizo clic en las cosas correctas" sino "la prueba que escribió demostró algo". El propio material del vendedor dice que los humanos todavía deciden. Ésta es la decisión que importa.
Una marca de verificación verde le indica que se ejecutó la prueba. Nunca te dice que la prueba fue correcta.
Preguntas comunes
¿Qué es un oráculo de prueba?
La parte de una prueba que decide si se aprueba o no. Una comprobación sobre un mensaje de éxito es un oráculo débil. Una comprobación sobre el estado verificado de forma independiente, como los datos después de una recarga o una consulta de API, es sólida.
¿Una prueba completa aprobada demuestra que la función funciona?
No. Prueba que las condiciones específicas que afirmó la prueba eran verdaderas. Si la comprobación solo observa la interfaz de usuario, la función se puede interrumpir mientras la prueba permanece verde.
¿Cómo audito las pruebas escritas por un agente de IA?
Para cada prueba, pregunte qué afirma y si podría pasar mientras la característica no funciona. Prefiera pruebas que verifiquen el estado persistente a través de una segunda ruta: recarga, consulta de API o un registro fuera de banda.