En esta página
Un test superado puede esconder una regla ausente. En este caso ilustrativo, se pide a un agente que conecte una tienda con una plataforma de correo. Un servidor de prueba acepta una actualización de contacto y devuelve un pulcro 200. El agente termina y la prueba pasa.
El destino real tiene una regla más: el atributo personalizado debe declararse antes de que una actualización de contacto pueda asignarle un valor. El servidor de prueba no modeló esa regla. Su resultado verde demuestra algo sobre el agente en el mundo de la prueba. No demuestra nada sobre la regla ausente en el mundo real.
Ese es el pacto central de la simulación. Hace repetibles acciones peligrosas o costosas. También crea un segundo sistema cuyo comportamiento puede alejarse del primero.
Un sustituto permite probar acciones
Para probar a un agente que actúa, dale un objetivo, un entorno y un estado final observable. Una fuente sobre entornos simulados para agentes describe esta estructura para tareas de navegador y trabajo intelectual. El entorno permite al comprobador comparar lo que dejó el agente con un resultado conocido como correcto.
En una integración, el sustituto podría ofrecer pocas operaciones de destino: listar campos, crear un contacto, actualizarlo y leerlo. Podría contener datos de prueba con un campo FNAME declarado y un campo CUSTOM_TIER ausente. Una prueba podría pedir al agente que proponga una correspondencia y luego rechazar una escritura que use CUSTOM_TIER antes de que exista su definición.
El sustituto resulta útil porque cada ejecución empieza en el mismo estado. Puedes cambiar una sola condición cada vez: un campo ausente, permiso denegado, una versión de esquema antigua o un identificador ambiguo. Puedes comparar la secuencia de llamadas del agente y el estado resultante entre modelos o prompts.
Es más sólido que una pregunta solo textual sobre lo que el agente haría. Comprueba lo que llamó realmente en un mundo controlado.
Da a los datos de prueba un estado anterior y posterior a cada llamada, no solo una respuesta prefabricada. Si el agente crea dos veces un contacto, la segunda llamada debe revelar el comportamiento de duplicado que quieres probar. Si lee un campo después de escribirlo, la lectura debe devolver el estado almacenado. De otro modo, puede pasar por enviar una solicitud plausible mientras la prueba nunca descubre si la secuencia produjo el registro previsto.
La fidelidad es parte de la prueba
Una objeción razonable es: «El proveedor tiene un entorno de prueba; ¿para qué construir otro?». Utiliza el entorno del proveedor cuando admita el caso que necesitas y mantenga seguros los datos. Un sustituto local merece el esfuerzo cuando necesitas reinicios deterministas, fallos deliberados o probar llamadas que el entorno del proveedor no permite preparar. También exige mantenimiento. Toda regla modelada puede estar equivocada o quedar obsoleta.
La API oficial de contactos de Brevo indica que los atributos deben existir en la cuenta y que los valores de tipo incorrecto se ignoran. Un sustituto que rechazara cualquier valor mal formado actuaría de forma distinta a ese caso documentado. Podría enseñar al agente a esperar un error que nunca llegará.
Anota qué comportamientos del proveedor cubre el sustituto. Mantén unas pocas pruebas del contrato frente a la API real o su entorno de prueba compatible. Cuando una prueba encuentre una diferencia, actualiza el sustituto y añade el caso que la reveló. La simulación es un modelo del proveedor, no lo sustituye.
La misma disciplina se aplica al tiempo. Un sustituto que hace visible toda escritura al instante quizá no detecte un flujo que lee demasiado pronto. Uno que retrasa todas las escrituras puede inventar fallos que el proveedor no produce. Modela el tiempo solo donde afecte a la decisión probada e indica qué queda fuera. Una prueba superada tendrá así un significado preciso: el agente completó estas acciones bajo estas reglas modeladas.
La guía de Tajo sobre el conector de Brevo explica el mismo problema desde el lado de la tienda: una solicitud exitosa puede dejar un campo ausente. La prueba sirve solo si comprueba el campo, no únicamente la respuesta HTTP.
Un destino simulado prueba al agente bajo reglas modeladas. Las comprobaciones del contrato comparan esas reglas con el destino real antes de una vista previa limitada.
Pasa del ensayo seguro a pruebas limitadas
Una simulación superada debe conducir a una pequeña vista previa real. Elige algunos registros con estados de destino esperados explícitos. Incluye uno normal, uno sin un campo opcional y otro cuyo consentimiento prohíba usarlo para marketing. Verifica lo que almacena de verdad el destino. No deduzcas el resultado solo de la solicitud enviada.
La vista previa sintética y la comprobación del destino responden a preguntas distintas. La vista de asignación de Tajo prueba una conversión sin escribir en el destino. La vista de actividad propuesta muestra el paso posterior: incluso una actualización aplicada requiere comprobar el estado final. Dejar ese paso pendiente evita confundir el ensayo con una prueba.
Una escritura terminada aún necesita pruebas
¿Terminó la sincronización del cliente?
Escritura aplicada. Verificación pendiente.
Todavía no se ha comprobado el estado del destino.
Actividad de sincronización
- Solicitud aceptada
- Actualización aplicada
- Comprobación del destino pendiente
Ejecución de ejemplo · 14:32 UTC
Lo que sabemos
- Respuesta del proveedor
- Aceptada
- Resultado de la escritura
- Aplicada
- Lectura del destino
- Pendiente
Una llamada correcta no demuestra el estado final.
Diseño propuesto inspirado en el registro de actividad de Tajo. Esta ilustración añade un estado de verificación; no afirma que ya exista la lectura del destino.
La vista previa debe tener un alcance estrecho y una condición de parada clara. Un fallo debe impedir la activación general y señalar la diferencia exacta: definición del campo, identificador, tipo, permiso o tiempo. Una vista previa superada no prueba que todos los registros futuros actúen igual, pero establece que el contrato funciona hoy para los casos elegidos.
Esta secuencia separa dos preguntas. La simulación pregunta: «¿Sigue el agente la regla diseñada cuando controlamos el mundo?». La vista previa real pregunta: «¿Encaja la regla diseñada con esta cuenta del proveedor?». Una no puede sustituir a la otra.
La guía de ETL inversa explica por qué el trabajo final se repite con muchos registros. Esa repetición amplifica cualquier diferencia que quede entre el contrato simulado y el real.
Ensaya en un mundo que puedas reiniciar. Después inspecciona el que no puedes.
Preguntas frecuentes
¿Qué puede probar un destino simulado?
Puede comprobar si el agente elige las llamadas esperadas, respeta los permisos, gestiona errores conocidos y deja el estado esperado dentro de la simulación.
¿Qué no puede demostrar?
No puede establecer que su modelo del proveedor sea completo. El comportamiento no documentado, los tiempos y la configuración propia de una cuenta pueden diferir de la simulación.
¿Qué debe hacerse tras superar la simulación?
Ejecuta una vista previa o una prueba limitada contra el destino real y después inspecciona el estado resultante antes de una activación general.