Veai mostró cómo prueba un agente de IA en JetBrains IDE sin dependencia del modelo

Veai explicó cómo construyó pruebas de interfaz de usuario para su agente de IA dentro del IDE JetBrains de manera que las pruebas no dependieran de los caprichos del modelo de lenguaje. El equipo separó las pruebas de la interfaz, la lógica empresarial y el propio LLM, y luego armó un pipeline estable para PRs y ejecuciones nocturnas.

Por qué esto es difícil

El principal problema con estos productos es que la misma solicitud a un LLM puede devolver diferentes formulaciones, longitud de respuesta e incluso diferentes formatos de salida. Si prueba un complemento de IA como un chatbot común y espera un texto específico, las pruebas de interfaz se convierten rápidamente en una lotería.

Al mismo tiempo, una parte significativa del producto es bastante determinista: configuraciones del usuario, transiciones entre estados del chat, botones, insignias de habilidades, historial de conversaciones y la lógica empresarial interna del complemento. Exactamente esto es lo que Veai decidió separar en una capa de automatización dedicada.

El equipo opera con un principio simple: la calidad de la respuesta del modelo y la funcionalidad de la interfaz son preocupaciones separadas, y no debería mezclarlas en una sola prueba. El proyecto ya tenía pruebas en otros niveles, incluyendo pruebas de modelos de IDE, escenarios para diferentes proveedores de LLM y un benchmark de agente separado. Por lo tanto, la automatización de interfaz se convirtió en la cúspide de la pirámide de pruebas, en lugar de un intento de reemplazar todo lo demás.

Este enfoque es importante para un complemento IDE: el agente responde tanto en la ventana de chat como a través de la terminal, lo que significa que el número de lugares donde una prueba puede fallar aleatoriamente es significativamente mayor que con una interfaz web común.

Cómo estructuraron las pruebas

Para evitar confusiones entre objetivos, Veai dividió las ejecuciones de prueba en varios modos. Las pruebas de humo se ejecutan con cada solicitud de extracción y verifican la funcionalidad básica de la interfaz sin llamadas reales a LLM. Las ejecuciones completas se inician por la noche, funcionan con servidores reales y pasan por toda la cadena desde el complemento hasta la respuesta del modelo. También existe un benchmark separado: no pruebas de interfaz, sino una evaluación de escenarios de usuario y calidad del agente utilizando el principio LLM-as-a-Judge.

Como resultado, el equipo detecta regresiones de interfaz más rápidamente durante el día y no pierde la verificación integral del producto durante la noche.

• Humo con cada PR: verificación de interfaz y lógica básica sin carga de LLM
• Completo por la noche: funcionamiento con servidor real y espera de respuesta en la interfaz
• Benchmark separadamente: evaluación de escenarios de agente y calidad de resultado
• Ejecución paralela en diferentes IDEs: cobertura más amplia sin aumentar el esfuerzo manual

En una ejecución completa, los desarrolladores utilizan un mensaje muy corto — 2+2=? Mantenlo breve. Pero el objetivo de la prueba no es ver específicamente el número 4. El punto es diferente: después de las precondiciones necesarias, el agente debe alcanzar un estado Ready, recibir una respuesta del servidor, transmitir correctamente los tokens y mostrar el resultado en la interfaz. Este escenario no prueba la creatividad del modelo, sino que la combinación de complemento IDE, servidor de licencias, servidor LLM y bibliotecas internas no se ha roto después del último cambio.

"No estamos intentando obtener la respuesta 4"

Lo que ayudó en CI

Desde una perspectiva técnica, Veai se basa en las bibliotecas JetBrains Starter y Driver. Starter prepara el IDE, configura el proyecto de prueba y recopila artefactos de ejecución, mientras que Driver trabaja con la interfaz real y permite describir elementos utilizando enfoques de Page Object y DSL. Si los localizadores son insuficientes, el equipo agrega accessibleName al código del producto o ajusta las reglas de ofuscación para mantener los elementos detectables.

Parte del estado se prepara de antemano a través de configuraciones XML del complemento, por lo que las pruebas no necesitan pasar por la pantalla de bienvenida y la incorporación cada vez. Otro elemento importante es el acceso al estado interno del IDE a través de JMX. Esto permite no solo hacer clic en la interfaz, sino también verificar qué se escribió realmente en el chat del agente, qué proveedor se seleccionó y cómo se ve el estado JSON desde la perspectiva del complemento.

Para CI, el equipo mantiene una matriz de diferentes versiones de IntelliJ Platform, múltiples IDEs de JetBrains, feature flags y compilaciones ofuscadas. Las pruebas pesadas se ejecutan por la noche, Xvfb se usa en Linux, y para reducir el ruido, se habilitan reintentos limitados: no más de un reinicio de prueba y no más de tres fallos por ejecución.

El efecto práctico ya es visible: docenas de pruebas de interfaz cubren configuraciones de complemento, transiciones entre estados de chat, llamadas de habilidades, historial de conversaciones e inicio de sesión de nuevo usuario. En los primeros meses, estas pruebas encontraron errores bastante prácticos: después de agregar arrastrar y soltar archivos, copiar y pegar se rompió; la barra de progreso de contexto no consideraba todos los proveedores de LLM; la seleción de agente en la interfaz tampoco funcionaba para todas las configuraciones; y el escenario de recuperación de errores comenzó a parpadear visualmente junto con las pruebas. Las ejecuciones nocturnas incluso destacaron inestabilidad en una de las configuraciones de prueba del servidor LLM.

Lo que esto significa

Para productos con características de IA, esta es una buena orientación: no debería forzar que las pruebas de interfaz juzguen la calidad del modelo cuando es suficiente verificar la resiliencia de la interfaz y la cadena de integración. Separar partes deterministas y no deterministas del sistema hace que las pruebas sean más rápidas, más útiles y notabledmente más honestas tanto para desarrolladores como para QA.