Veai mostrou como testa um agente de IA no JetBrains IDE sem dependência do modelo

Veai compartilhou como construiu testes de UI para seu agente de IA dentro da IDE JetBrains para que os testes não dependessem dos caprichos do modelo de linguagem. A equipe separou os testes da interface, da lógica de negócio e do próprio LLM, e depois montou um pipeline estável para PRs e execuções noturnas.

Por que isso é difícil

O principal problema com esses produtos é que a mesma solicitação a um LLM pode retornar diferentes formulações, comprimento de resposta e até formatos de saída diferentes. Se você testar um plugin de IA como um chatbot comum e esperar um texto específico, os testes de UI rapidamente se tornam uma loteria.

Ao mesmo tempo, uma parte significativa do produto é bastante determinística: configurações do usuário, transições entre estados do chat, botões, emblemas de habilidades, histórico de conversas e a lógica de negócio interna do plugin. Foi exatamente isso que a Veai decidiu separar em uma camada de automação dedicada.

A equipe opera com um princípio simples: a qualidade da resposta do modelo e a funcionalidade da interface são preocupações separadas, e misturá-las em um único teste não é aconselhável. O projeto já tinha verificações em outros níveis, incluindo testes de modelo IDE, cenários para diferentes provedores de LLM e um benchmark de agente separado. Por isso, a automação de UI tornou-se o topo da pirâmide de testes, e não uma tentativa de substituir tudo o mais.

Essa abordagem é importante para um plugin IDE: o agente responde tanto na janela de chat quanto pelo terminal, o que significa que o número de lugares onde um teste pode falhar aleatoriamente é significativamente maior do que em uma interface web comum.

Como estruturaram os testes

Para evitar confusão entre objetivos, a Veai dividiu as execuções de teste em vários modos. Testes de smoke são executados com cada solicitação pull e verificam a funcionalidade básica da interface sem chamadas reais de LLM. Execuções completas começam à noite, funcionam com servidores reais e passam por toda a cadeia do plugin até a resposta do modelo. Existe também um benchmark separado: não testes de UI, mas uma avaliação de cenários do usuário e qualidade do agente usando o princípio LLM-as-a-Judge.

Como resultado, a equipe detecta regressões de UI mais rápido durante o dia e não perde a verificação de ponta a ponta do produto à noite.

• Smoke com cada PR: verificação de UI e lógica básica sem carga de LLM
• Completo à noite: trabalho com servidor real e espera por resposta na interface
• Benchmark separadamente: avaliação de cenários de agente e qualidade de resultado
• Execução paralela em diferentes IDEs: cobertura mais ampla sem aumentar esforço manual

Em uma execução completa, os desenvolvedores usam um prompt muito curto — 2+2=? Mantenha breve. Mas o objetivo do teste não é ver o número 4 especificamente. O ponto é diferente: após as pré-condições necessárias, o agente deve alcançar um estado Ready, receber uma resposta do servidor, transmitir tokens corretamente e exibir o resultado na interface. Esse cenário não testa a criatividade do modelo, mas sim se a combinação de plugin IDE, servidor de licenças, servidor LLM e bibliotecas internas não quebrou após a última alteração.

"Não estamos tentando obter a resposta 4"

O que ajudou no CI

Do ponto de vista técnico, a Veai se baseia nas bibliotecas JetBrains Starter e Driver. Starter prepara a IDE, configura o projeto de teste e coleta artefatos de execução, enquanto Driver trabalha com a interface real e permite descrever elementos usando abordagens de Page Object e DSL. Se os localizadores forem insuficientes, a equipe adiciona accessibleName ao código do produto ou ajusta as regras de ofuscação para manter os elementos descobertos.

Parte do estado é preparada com antecedência através de configurações XML do plugin, portanto os testes não precisam passar pela tela de boas-vindas e onboarding a cada vez. Outro elemento importante é o acesso ao estado interno da IDE através de JMX. Isso permite não apenas clicar na interface, mas também verificar o que foi realmente escrito no chat do agente, qual provedor foi selecionado e como o estado JSON parece do ponto de vista do plugin.

Para CI, a equipe mantém uma matriz de diferentes versões da IntelliJ Platform, múltiplas IDEs JetBrains, feature flags e compilações ofuscadas. Verificações pesadas são executadas à noite, Xvfb é usado no Linux, e para reduzir ruído, retentativas limitadas são habilitadas: no máximo um reinício de teste e no máximo três falhas por execução.

O efeito prático já é visível: dezenas de testes de UI cobrem configurações de plugin, transições entre estados de chat, chamadas de habilidades, histórico de conversas e login de novo usuário. Nos primeiros meses, esses testes encontraram bugs bastante práticos: depois de adicionar arrastar e soltar de arquivo, copiar e colar quebrou; a barra de progresso de contexto não contabilizava todos os provedores de LLM; a seleção de agente na UI também não funcionava para todas as configurações; e o cenário de recuperação de erro começou a piscar visualmente junto com os testes. Execuções noturnas até destacaram instabilidade em uma das configurações de teste do servidor LLM.

O que isso significa

Para produtos com recursos de IA, esta é uma boa orientação: você não deve forçar testes de UI a julgarem a qualidade do modelo quando é suficiente verificar a resiliência da interface e a cadeia de integração. Separar partes determinísticas e não determinísticas do sistema torna os testes mais rápidos, mais úteis e notavelmente mais honestos tanto para desenvolvedores quanto para QA.