Veai a montré comment tester un agent IA dans JetBrains IDE sans dépendance du modèle

Veai a expliqué comment elle a construit des tests d'interface utilisateur pour son agent d'IA dans l'IDE JetBrains de sorte que les tests ne dépendent pas des caprices du modèle de langage. L'équipe a séparé les tests de l'interface, de la logique métier et du LLM lui-même, puis a assemblé un pipeline stable pour les PR et les exécutions nocturnes.

Pourquoi c'est difficile

Le problème principal avec ces produits est que la même requête à un LLM peut retourner différentes formulations, longueur de réponse et même différents formats de sortie. Si vous testez un plugin d'IA comme un chatbot ordinaire et attendez un texte spécifique, les tests d'interface deviennent rapidement une loterie.

En même temps, une partie significative du produit est tout à fait déterministe : paramètres utilisateur, transitions entre états du chat, boutons, badges de compétences, historique de conversation et logique métier interne du plugin. C'est exactement ce que Veai a décidé de séparer dans une couche d'automatisation dédiée.

L'équipe opère selon un principe simple : la qualité de la réponse du modèle et la fonctionnalité de l'interface sont des préoccupations distinctes, et il ne faut pas les mélanger dans un seul test. Le projet avait déjà des vérifications à d'autres niveaux, incluant des tests de modèle IDE, des scénarios pour différents fournisseurs de LLM et un benchmark d'agent séparé. Par conséquent, l'automatisation de l'interface est devenue le sommet de la pyramide de test, plutôt qu'une tentative de remplacer tout le reste.

Cette approche est importante pour un plugin IDE : l'agent répond à la fois dans la fenêtre de chat et via le terminal, ce qui signifie que le nombre d'endroits où un test pourrait échouer aléatoirement est considérablement plus élevé qu'avec une interface web ordinaire.

Comment ils ont structuré les tests

Pour éviter la confusion entre les objectifs, Veai a divisé les exécutions de test en plusieurs modes. Les tests de fumée s'exécutent à chaque demande de fusion et vérifient la fonctionnalité de base de l'interface sans appels réels au LLM. Les exécutions complètes démarrent la nuit, fonctionnent avec des serveurs réels et passent par toute la chaîne du plugin à la réponse du modèle. Il y a également un benchmark séparé : non des tests d'interface, mais une évaluation des scénarios utilisateur et de la qualité de l'agent selon le principe LLM-as-a-Judge.

En conséquence, l'équipe détecte les régressions d'interface plus rapidement pendant la journée et ne perd pas la vérification de bout en bout du produit la nuit.

• Fumée à chaque PR : vérification de l'interface et logique de base sans charge LLM
• Complet la nuit : fonctionnement avec serveur réel et attente de réponse dans l'interface
• Benchmark séparément : évaluation des scénarios d'agent et qualité des résultats
• Exécution parallèle sur différents IDE : couverture plus large sans augmentation du travail manuel

Dans une exécution complète, les développeurs utilisent une requête très courte — 2+2=? Gardez-la brève. Mais l'objectif du test n'est pas de voir spécifiquement le nombre 4. Le point est différent : après les préconditions nécessaires, l'agent doit atteindre un état Ready, recevoir une réponse du serveur, transmettre correctement les jetons et afficher le résultat dans l'interface. Ce scénario ne teste pas la créativité du modèle, mais plutôt que la combinaison du plugin IDE, du serveur de licences, du serveur LLM et des bibliothèques internes ne s'est pas cassée après la dernière modification.

"Nous ne cherchons pas à obtenir la réponse 4"

Ce qui a aidé en CI

D'un point de vue technique, Veai s'appuie sur les bibliothèques JetBrains Starter et Driver. Starter prépare l'IDE, configure le projet de test et collecte les artefacts d'exécution, tandis que Driver travaille avec l'interface réelle et permet de décrire les éléments en utilisant les approches Page Object et DSL. Si les localisateurs sont insuffisants, l'équipe ajoute accessibleName au code produit ou ajuste les règles d'obfuscation pour garder les éléments découvrables.

Une partie de l'état est préparée à l'avance via les paramètres XML du plugin, donc les tests n'ont pas besoin de passer par l'écran de bienvenue et l'onboarding à chaque fois. Un autre élément important est l'accès à l'état interne de l'IDE via JMX. Cela permet non seulement de cliquer sur l'interface, mais aussi de vérifier ce qui a été réellement écrit dans le chat de l'agent, quel fournisseur a été sélectionné et à quoi ressemble l'état JSON du point de vue du plugin.

Pour CI, l'équipe maintient une matrice de différentes versions de la plateforme IntelliJ, plusieurs IDE JetBrains, des indicateurs de fonctionnalité et des builds obfusqués. Les vérifications lourdes s'exécutent la nuit, Xvfb est utilisé sur Linux, et pour réduire le bruit, les retentatives limitées sont activées : pas plus d'un redémarrage de test et pas plus de trois défaillances par exécution.

L'effet pratique est déjà visible : des dizaines de tests d'interface couvrent les paramètres du plugin, les transitions entre états du chat, les appels de compétences, l'historique de conversation et la connexion de nouvel utilisateur. Au cours des premiers mois, ces tests ont trouvé des bugs assez pratiques : après l'ajout du glisser-déposer de fichiers, la copie et le collage ont été cassés ; la barre de progression du contexte ne tenait pas compte de tous les fournisseurs de LLM ; la sélection d'agent sur l'interface ne fonctionnait pas non plus pour toutes les configurations ; et le scénario de récupération d'erreur a commencé à clignoter visuellement avec les tests. Les exécutions nocturnes ont même mis en évidence l'instabilité dans l'une des configurations de test du serveur LLM.

Ce que cela signifie

Pour les produits avec des fonctionnalités d'IA, c'est une bonne ligne directrice : vous ne devriez pas forcer les tests d'interface à juger la qualité du modèle lorsqu'il suffit de vérifier la résilience de l'interface et la chaîne d'intégration. Séparer les parties déterministes et non déterministes du système rend les tests plus rapides, plus utiles et notabledment plus honnêtes pour les développeurs et QA.