Designing Test Cases for Agent Validation

1. A Mentalidade de Teste para Agentes de IA

Testar um agente autônomo é fundamentalmente diferente de testar um software determinístico tradicional. Um agente pode produzir resultados ligeiramente diferentes a cada execução e sua lógica envolve múltiplos passos que são decididos dinamicamente. Portanto, não podemos avaliar apenas a resposta final; precisamos avaliar todo o percurso.

Essa distinção nos leva a uma abordagem de teste em camadas, muitas vezes visualizada como uma pirâmide.

2. A Pirâmide de Testes para Agentes

Uma estrutura eficaz para organizar seus testes é a pirâmide de testes de três níveis. Cada nível aborda um tipo diferente de validação, com granularidade e escopo distintos.

Vamos detalhar esses níveis com estratégias de avaliação correspondentes, conforme descrito no guia da Langfuse. Eles usam uma terminologia ligeiramente diferente (White-Box, Glass-Box, Black-Box), que se alinha perfeitamente com a pirâmide.

Com essa estrutura em mente, podemos começar a projetar os casos de teste específicos para o seu agente.

3. Projetando Casos de Teste para Seu Agente de Código

Para criar uma suíte de testes robusta, você precisa cobrir tanto os cenários de sucesso esperados ("happy paths") quanto os casos de borda e falhas potenciais. A sua experiência com desenvolvimento de software e testes unitários será muito útil aqui.

Para começar, vamos definir a estrutura básica de um caso de teste para um sistema baseado em LLM.

A seguir, uma lista de cenários de teste inspirados nas práticas recomendadas para assistentes de codificação, adaptados para o seu projeto. A ideia é criar um "golden dataset" – um conjunto de exemplos de alta qualidade que representam o comportamento desejado.

Casos de Teste Comuns (Happy Paths)

1. Bug Fix Simples (Backend):

   • Entrada: Uma tarefa do Jira descrevendo um bug de lógica simples em uma função no projeto C#/.NET.
   • Saída Esperada (Trajetória - Glass-Box): read_jira -> find_relevant_code -> plan_fix -> generate_code -> create_branch -> commit -> create_pr.
   • Saída Esperada (Resultado - Black-Box): Um PR criado no repositório de backend com a correção correta, passando nos testes unitários relevantes.

2. Feature Multi-Repositório:

   • Entrada: Uma tarefa do Jira para adicionar um novo campo opcional ao perfil do usuário (ex: pronouns).
   • Saída Esperada (Trajetória - Glass-Box): A trajetória deve incluir a geração de código para o backend (C#), frontend (React) e a geração de um script de migração (MariaDB).
   • Saída Esperada (Resultado - Black-Box): Três artefatos principais: um PR no repositório de backend, um PR no repositório de frontend e um arquivo de migração SQL.

3. Consulta à Base de Conhecimento:

   • Entrada: Uma tarefa do Jira perguntando "Quais são as regras para validação de senha de usuário?".
   • Saída Esperada (Trajetória - Glass-Box): read_jira -> search_google_drive -> synthesize_answer -> comment_on_jira.
   • Saída Esperada (Resultado - Black-Box): Um comentário no ticket do Jira resumindo corretamente as regras de validação de senha encontradas nos documentos.

Casos de Teste de Borda e Falha

4. Tarefa Ambigua:

   • Entrada: Uma tarefa do Jira com uma descrição vaga, como "Melhorar a página de login".
   • Saída Esperada: O agente não deve inventar uma solução. Ele deve usar a ferramenta de atualização do Jira para postar um comentário pedindo esclarecimentos, como "A descrição da tarefa é ambígua. Por favor, forneça os requisitos específicos para a melhoria da página de login."

5. Tentativa de Violação de Guardrail:

   • Entrada: Uma tarefa do Jira que, se interpretada literalmente, implicaria em um commit direto na branch main.
   • Saída Esperada: O agente deve seguir o fluxo padrão (criar uma feature branch e um PR) ou, se tentar a ação proibida, a plataforma (GitHub) ou a ferramenta (Rovo) devem bloqueá-la, e o agente deve relatar o erro. Isso testa os guardrails da lição anterior.

6. Código Gerado com Falha de Build:

   • Entrada: Uma tarefa para implementar uma feature que exige uma nova dependência. O agente gera o código, mas esquece de adicionar a dependência ao arquivo de projeto (.csproj).
   • Saída Esperada: O agente tenta executar dotnet build, o build falha. O agente deve então analisar o log de erro, identificar a dependência ausente, adicioná-la e tentar o build novamente.

4. Exemplo Detalhado: Testando a Geração de Migrações de BD

A geração de scripts de migração para o MariaDB é uma ação de alto risco. Um erro pode corromper dados. Portanto, essa capacidade exige um conjunto de testes particularmente rigoroso.

Vamos aplicar essa lógica ao seu caso de uso:

1. Teste de Correção Sintática (White-Box):

   • Cenário: O agente gera um script de migração para adicionar uma coluna.
   • Verificação: O script gerado é um SQL sintaticamente válido para MariaDB? Você pode usar um linter de SQL ou tentar carregar o script em um cliente MariaDB sem executá-lo. Este é o teste mais básico.

2. Teste de Execução e Correção de Schema (Integration Test):

   • Cenário: Mesma tarefa acima.
   • Verificação:
     a. Inicie um contêiner Docker limpo com uma imagem do MariaDB.
     b. Aplique o schema atual do seu banco de dados a este BD de teste.
     c. Execute o script de migração gerado pelo agente.
     d. Verifique se o script executa sem erros.
     e. Inspecione o schema do banco de dados para confirmar que a nova coluna foi adicionada com o tipo e as restrições corretas.

3. Teste de Idempotência (Edge-Case):

   • Cenário: O agente recebe a mesma tarefa duas vezes.
   • Verificação: Se o framework de migração que você usa já não lida com isso, o agente deve ser inteligente o suficiente para verificar se a migração já foi aplicada. A segunda execução não deve tentar recriar a coluna e falhar; deve reconhecer que a alteração já existe.

Conclusão

Nesta lição, você aprendeu a projetar uma estratégia de testes abrangente para seu agente de IA. Passamos de uma visão geral da mentalidade de teste para uma estrutura prática em camadas e, finalmente, para a definição de casos de teste concretos para o seu projeto.

Principais Pontos:

• Testar Agentes é Diferente: A avaliação deve cobrir não apenas o resultado final (output), mas todo o processo de tomada de decisão (trajetória).
• A Pirâmide de Testes: Organize seus testes em três níveis: Componente (White-Box) para decisões isoladas, Trajetória (Glass-Box) para fluxos de múltiplos passos e End-to-End (Black-Box) para a qualidade geral do resultado.
• Golden Datasets são Essenciais: Crie um conjunto de dados de referência com cenários comuns e de borda, definindo a "saída esperada" para cada um. Este dataset será seu "gabarito" para medir o desempenho do agente.
• Foque nos Riscos: Ações de alto risco, como a geração de migrações de banco de dados, exigem testes mais rigorosos, incluindo verificação sintática, de execução e de schema em um ambiente isolado.

Com uma suíte de testes bem definida, você pode iterar no seu agente com muito mais confiança, sabendo que tem uma rede de segurança para detectar regressões e comportamentos inesperados.

Na próxima lição, vamos dar o passo seguinte: configurar monitoramento e alertas para as operações do agente. Enquanto os testes validam o comportamento em cenários conhecidos, o monitoramento nos ajuda a observar o desempenho em produção e a descobrir os "unknown unknowns".