Veai mostra como testa um agente de IA nas IDEs da JetBrains sem depender do modelo

A Veai contou como montou os testes de UI do seu agente de IA dentro das IDEs da JetBrains para que as verificações não dependam dos caprichos do modelo de linguagem. A equipe separou o teste da interface, da lógica de negócio e do próprio LLM e, com isso, montou um pipeline estável para PRs e execuções noturnas.

Por que é difícil

O principal problema desse tipo de produto é que a mesma requisição a um LLM pode retornar redações diferentes, respostas de tamanhos distintos e até um formato de saída diferente. Se o plugin de IA for testado como um chatbot comum, esperando um texto específico, os testes de UI viram rapidamente uma loteria.

Ao mesmo tempo, boa parte do produto é perfeitamente determinística: configurações do usuário, transições entre estados do chat, botões, badges de skills, histórico de diálogos e a lógica de negócio interna do plugin. A Veai decidiu levar justamente essa parte para uma camada de automação separada.

A equipe parte de um princípio simples: a qualidade da resposta do modelo e o funcionamento da interface são tarefas diferentes, e não vale misturá-las no mesmo teste. O projeto já tinha verificações em outros níveis, incluindo testes do modelo da IDE, cenários para diferentes provedores de LLM e um benchmark de agentes independente. Por isso, a automação de UI virou o topo da pirâmide de testes, e não uma tentativa de substituir todo o resto.

Isso é importante para um plugin de IDE: o agente responde tanto na janela de chat quanto pelo terminal, o que significa que há bem mais pontos em que um teste pode falhar de forma intermitente do que numa interface web comum.

Como os testes foram organizados

Para não misturar objetivos, a Veai dividiu as execuções em vários modos. Os testes smoke rodam em cada pull request e verificam o funcionamento básico da interface sem chamada real ao LLM. As execuções full começam à noite, já trabalham com um servidor real e percorrem toda a cadeia, do plugin até a resposta do modelo. Há ainda um benchmark à parte: não são testes de UI, e sim uma avaliação de cenários de usuário e da qualidade do agente, segundo o princípio LLM-as-a-Judge.

Com isso, a equipe pega 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 em cada PR: verificação da UI e da lógica básica sem carga no LLM
• Full à noite: trabalho com servidor real e espera pela resposta na interface
• Benchmark separado: avaliação dos cenários do agente e da qualidade do resultado
• Execução paralela em diferentes IDEs: cobertura maior sem aumentar a rotina manual

Na execução completa, os desenvolvedores usam uma requisição muito curta: 2+2=? Responda de forma breve. Mas o objetivo do teste não é ver exatamente o número 4. O ponto é outro: depois das pré-condições necessárias, o agente deve chegar ao estado Ready, receber a resposta do servidor, concluir corretamente o streaming dos tokens e exibir o resultado na interface. Esse cenário não verifica a criatividade do modelo, e sim se a combinação de plugin da IDE, servidor de licenças, servidor do LLM e bibliotecas internas não quebrou após mais uma alteração.

"Não buscamos obter a resposta 4".

O que ajudou no CI

Do lado técnico, a Veai se apoia nas bibliotecas JetBrains Starter e Driver. O Starter prepara a IDE, configura o projeto de teste e coleta os artefatos da execução, enquanto o Driver trabalha com a interface real e permite descrever elementos por meio de Page Object e de uma abordagem DSL. Se os localizadores não bastam, a equipe adiciona accessibleName ao código do produto ou ajusta as regras de ofuscação para que os elementos continuem localizáveis.

Parte do estado é preparada antecipadamente por meio das configurações XML do plugin, então os testes não precisam passar toda vez pela tela Welcome e pelo onboarding.

Outro elemento importante é o acesso ao estado interno da IDE via JMX. Isso permite não só clicar na interface, mas também verificar o que realmente foi gravado no chat do agente, qual provedor está selecionado e como é o estado JSON do ponto de vista do plugin.

Para o CI, a equipe mantém uma matriz com diferentes versões da IntelliJ Platform, várias IDEs da JetBrains, feature flags e builds ofuscadas. As verificações pesadas rodam à noite, no Linux se usa Xvfb e, para reduzir o ruído, há retentativas limitadas: no máximo um reinício por teste e no máximo três falhas em toda a execução.

O efeito prático já aparece: algumas dezenas de testes de UI cobrem as configurações do plugin, as transições entre estados do chat, as chamadas de skills, o histórico de diálogos e a entrada de um novo usuário. Nos primeiros meses, essas verificações encontraram bugs bem concretos: depois da adição do drag and drop de arquivos, o copy and paste quebrou; a barra de progresso do contexto não considerava todos os provedores de LLM; a escolha do agente na UI também não funcionava em todas as configurações; e o cenário de recuperação após erro passou a piscar visualmente junto com os testes. As execuções noturnas ainda destacaram a instabilidade de uma das configurações de teste do servidor do LLM.

O que isso significa

Para produtos com recursos de IA, é uma boa referência: não vale obrigar os testes de UI a avaliar a qualidade do modelo quando basta verificar a estabilidade da interface e da cadeia de integrações. Separar as partes determinísticas e não determinísticas do sistema torna os testes mais rápidos, mais úteis e bem mais honestos, tanto para desenvolvedores quanto para QA.