Veai montre comment elle teste un agent IA dans les IDE JetBrains sans dépendre du modèle

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

Pourquoi c'est difficile

Le principal problème de ces produits tient à ce qu'une même requête adressée à un LLM peut renvoyer des formulations différentes, des réponses de longueur variable et même un format de sortie différent. Si l'on teste un plugin d'IA comme un chatbot ordinaire en attendant un texte précis, les tests d'UI tournent vite à la loterie.

Dans le même temps, une part importante du produit est tout à fait déterministe : les paramètres de l'utilisateur, les transitions entre états du chat, les boutons, les badges de skills, l'historique des dialogues et la logique métier interne du plugin. Veai a décidé de confier précisément cette partie à une couche d'automatisation distincte.

L'équipe part d'un principe simple : la qualité de la réponse du modèle et le bon fonctionnement de l'interface sont deux sujets différents, et il vaut mieux ne pas les mélanger dans un même test. Le projet disposait déjà de vérifications à d'autres niveaux, notamment des tests du modèle de l'IDE, des scénarios pour différents fournisseurs de LLM et un benchmark d'agents distinct. L'automatisation de l'UI est donc devenue le sommet de la pyramide de tests, et non une tentative de remplacer tout le reste.

Cette approche compte pour un plugin d'IDE : l'agent répond à la fois dans la fenêtre de chat et via le terminal, de sorte que les endroits où un test peut devenir instable par accident sont nettement plus nombreux que dans une interface web ordinaire.

Comment les tests sont organisés

Pour ne pas confondre les objectifs, Veai a réparti les exécutions en plusieurs modes. Les tests smoke tournent dans chaque pull request et vérifient le fonctionnement de base de l'interface sans appel réel au LLM. Les exécutions full se lancent la nuit, utilisent un vrai serveur et parcourent toute la chaîne, du plugin jusqu'à la réponse du modèle. À part, il existe un benchmark : il ne s'agit pas de tests d'UI, mais d'une évaluation des scénarios utilisateur et de la qualité de l'agent selon le principe LLM-as-a-Judge.

Résultat : l'équipe repère plus vite les régressions d'UI en journée et ne perd pas la vérification de bout en bout du produit la nuit.

• Smoke dans chaque PR : vérification de l'UI et de la logique de base sans charge sur le LLM
• Full la nuit : travail avec un vrai serveur et attente de la réponse dans l'interface
• Benchmark à part : évaluation des scénarios de l'agent et de la qualité du résultat
• Exécution parallèle sur différents IDE : couverture plus large sans routine manuelle supplémentaire

Dans l'exécution complète, les développeurs utilisent une requête très courte : 2+2=? Réponds brièvement. Mais l'objectif du test n'est pas de voir précisément le chiffre 4. L'enjeu est ailleurs : après les préconditions nécessaires, l'agent doit atteindre l'état Ready, recevoir la réponse du serveur, terminer correctement le streaming des tokens et afficher le résultat dans l'interface. Ce scénario ne vérifie pas la créativité du modèle, mais que l'ensemble formé par le plugin de l'IDE, le serveur de licences, le serveur du LLM et les bibliothèques internes ne s'est pas effondré après la dernière modification.

« Nous ne cherchons pas à obtenir la réponse 4 ».

Ce qui a aidé en CI

Sur le plan 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 de l'exécution, tandis que Driver travaille avec l'interface réelle et permet de décrire les éléments via Page Object et une approche DSL. Lorsque les localisateurs ne suffisent pas, l'équipe ajoute accessibleName au code du produit ou ajuste les règles d'obfuscation afin que les éléments restent repérables.

Une partie de l'état est préparée à l'avance via les paramètres XML du plugin, si bien que les tests n'ont pas à repasser à chaque fois par l'écran Welcome et l'onboarding.

Un autre élément important est l'accès à l'état interne de l'IDE via JMX. Il permet non seulement de cliquer dans l'interface, mais aussi de vérifier ce qui a réellement été enregistré dans le chat de l'agent, quel fournisseur est sélectionné et à quoi ressemble l'état JSON du point de vue du plugin.

Pour la CI, l'équipe maintient une matrice de différentes versions d'IntelliJ Platform, de plusieurs IDE JetBrains, de feature flags et de builds obfusqués. Les vérifications lourdes tournent la nuit, Xvfb est utilisé sous Linux et, pour limiter le bruit, des relances limitées sont activées : pas plus d'un redémarrage par test et pas plus de trois échecs sur l'ensemble de l'exécution.

L'effet pratique est déjà visible : plusieurs dizaines de tests d'UI couvrent les paramètres du plugin, les transitions entre états du chat, les appels de skills, l'historique des dialogues et l'arrivée d'un nouvel utilisateur. Durant les premiers mois, ces vérifications ont débusqué des bugs très concrets : après l'ajout du drag and drop de fichiers, le copier-coller s'est cassé ; la barre de progression du contexte ne prenait pas en compte tous les fournisseurs de LLM ; le choix de l'agent dans l'UI ne fonctionnait pas non plus pour toutes les configurations ; et le scénario de reprise après erreur s'est mis à clignoter visuellement en même temps que les tests. Les exécutions nocturnes ont même mis en évidence l'instabilité d'une des configurations de test du serveur du LLM.

Ce que cela signifie

Pour les produits dotés de fonctions d'IA, c'est un bon repère : mieux vaut ne pas faire juger la qualité du modèle par les tests d'UI quand il suffit de vérifier la robustesse de l'interface et de la chaîne d'intégrations. Séparer les parties déterministes et non déterministes du système rend les tests plus rapides, plus utiles et nettement plus honnêtes, aussi bien pour les développeurs que pour le QA.