Nesta página
Um teste aprovado pode esconder uma regra ausente. Neste caso ilustrativo, um agente recebe a tarefa de conectar uma loja a uma plataforma de e-mail. Um servidor de teste aceita uma atualização de contato e retorna um elegante 200. O agente termina a tarefa e o teste passa.
O destino real tem uma regra adicional: o atributo personalizado precisa ser declarado antes que uma atualização de contato possa defini-lo. O servidor de teste não modelou essa regra. Seu resultado positivo comprova algo sobre o agente no mundo do teste. Não comprova nada sobre a regra ausente no mundo real.
Essa é a troca central da simulação. Ela torna repetíveis ações perigosas ou caras. Também cria um segundo sistema cujo comportamento pode se afastar do primeiro.
Um substituto permite testar ações
Para testar um agente que age, dê a ele um objetivo, um ambiente e um estado final observável. Uma discussão sobre ambientes simulados para agentes descreve essa estrutura para tarefas no navegador e trabalho de conhecimento. O ambiente permite que um verificador compare o que o agente deixou com um resultado conhecido como correto.
Em uma integração, o substituto poderia oferecer poucas operações de destino: listar campos, criar um contato, atualizar um contato e relê-lo. Poderia guardar dados de teste com um campo FNAME declarado e um campo CUSTOM_TIER ausente. Um teste poderia pedir que o agente propusesse um mapeamento e depois rejeitar uma gravação que use CUSTOM_TIER antes de existir uma definição.
O substituto é útil porque cada execução começa do mesmo estado. Você pode mudar uma condição por vez: campo ausente, permissão negada, versão antiga do esquema ou identificador ambíguo. Pode comparar a sequência de chamadas do agente e o estado resultante entre modelos ou prompts.
Isso é mais forte do que uma pergunta só textual sobre o que o agente faria. Testa o que ele realmente chamou em um mundo controlado.
Forneça aos dados de teste um estado antes e depois de cada chamada, não apenas uma resposta pronta. Se o agente criar um contato duas vezes, a segunda chamada deve revelar o comportamento de duplicação que você quer testar. Se ele ler um campo após gravá-lo, a leitura deve retornar o estado armazenado. Caso contrário, o agente pode passar ao enviar uma requisição plausível, enquanto o teste nunca descobre se a sequência produziu o registro pretendido.
A fidelidade faz parte do teste
Uma objeção justa seria: “O fornecedor tem um ambiente de testes; por que construir outro?”. Use o ambiente do fornecedor quando ele permitir o caso necessário e mantiver os dados seguros. Um substituto local vale o esforço quando você precisa de reinícios determinísticos, falhas deliberadas ou uma forma de testar chamadas que o ambiente do fornecedor não consegue preparar. Ele também exige manutenção. Cada regra modelada pode estar errada ou ficar desatualizada.
A API oficial de contatos da Brevo diz que os atributos devem existir na conta e que valores com tipo declarado incorreto são ignorados. Um substituto que rejeitasse todo valor malformado se comportaria de maneira diferente desse caso documentado. Ele poderia ensinar o agente a esperar um erro que nunca chega.
Registre quais comportamentos do fornecedor o substituto cobre. Mantenha algumas verificações do contrato na API real ou no ambiente de teste suportado. Quando uma verificação encontrar uma diferença, atualize o substituto e acrescente o caso que a expôs. A simulação é um modelo do fornecedor, não substitui o fornecedor.
A mesma disciplina vale para o tempo. Um substituto que torne toda gravação visível imediatamente pode deixar passar um fluxo que lê cedo demais. Um que atrase todas as gravações pode inventar falhas que o fornecedor não produz. Modele o tempo somente onde ele afeta a decisão testada e identifique o resto como fora da simulação. Assim, um teste aprovado terá significado preciso: o agente concluiu estas ações sob estas regras modeladas.
O guia da Tajo para o conector da Brevo descreve a mesma questão prática do ponto de vista da loja: uma requisição bem-sucedida pode deixar um campo ausente. O teste só ajuda se conferir o campo, não apenas a resposta HTTP.
Um destino simulado testa o agente sob regras modeladas. Verificações do contrato comparam essas regras ao destino real antes de uma prévia limitada.
Do ensaio seguro à evidência limitada
Uma simulação aprovada deve levar a uma pequena prévia real. Escolha poucos registros com estados esperados no destino claramente definidos. Inclua um registro normal, um sem campo opcional e outro cujo consentimento proíba o uso para marketing. Verifique o que o destino realmente armazena. Não deduza o resultado apenas dos dados enviados na requisição.
Uma prévia sintética e uma verificação do destino respondem a perguntas diferentes. A prévia de mapeamento do Tajo testa uma conversão sem gravar no destino. A visão de atividades proposta mostra o passo seguinte: até uma atualização aplicada requer conferir o estado no destino. Manter essa etapa pendente evita confundir o ensaio com uma prova.
Uma gravação concluída ainda precisa de provas
A sincronização do cliente terminou?
Gravação aplicada. Verificação pendente.
O estado no destino ainda não foi verificado.
Atividade da sincronização
- Solicitação aceita
- Atualização aplicada
- Verificação do destino pendente
Execução de exemplo · 14:32 UTC
O que sabemos
- Resposta do provedor
- Aceita
- Resultado da gravação
- Aplicada
- Leitura do destino
- Pendente
Uma chamada bem-sucedida não comprova o estado final.
Layout proposto com base no registro de atividades do Tajo. A ilustração acrescenta um estado de verificação; ela não afirma que a leitura do destino já esteja implementada.
A prévia deve ter escopo estreito e uma condição clara para parar. Uma falha deve impedir a ativação ampla e apontar para a diferença exata: definição de campo, identificador, tipo, permissão ou tempo. Uma prévia aprovada não comprova que todos os registros futuros se comportarão igual, mas estabelece que o contrato funciona hoje nos casos escolhidos.
Essa sequência separa duas perguntas. A simulação pergunta: “O agente segue a regra projetada quando controlamos o mundo?”. A prévia real pergunta: “A regra projetada corresponde a esta conta do fornecedor?”. Uma pergunta não substitui a outra.
O guia de ETL reverso explica por que o trabalho final se repete com muitos registros. A repetição amplia qualquer diferença entre os contratos simulado e real.
Ensaie em um mundo que você pode reiniciar. Depois inspecione o mundo que não pode.
Perguntas frequentes
O que um destino simulado pode testar?
Pode testar se o agente escolhe as chamadas esperadas, respeita permissões, trata erros conhecidos e deixa o estado esperado dentro da simulação.
O que ele não pode comprovar?
Não pode comprovar que seu modelo do fornecedor esteja completo. Comportamentos não documentados, tempos e configurações específicas de conta podem diferir da simulação.
O que deve acontecer depois de um teste simulado bem-sucedido?
Execute uma prévia ou teste limitado no destino real e examine o estado resultante antes de uma ativação ampla.