Imaginez que vous êtes un chef étoilé essayant d'apprendre à un sous-chef très talentueux, mais légèrement chaotique, comment cuisiner un plat parfait. Vous donnez au sous-chef une recette (le code) et lui demandez d'écrire un « test de dégustation » (un test unitaire) pour prouver que le plat fonctionne. Dans le monde du logiciel, ces « tests de dégustation » sont de petits programmes qui vérifient si une partie spécifique de code fait ce qu'elle est censée faire. Pendant des années, les humains ont écrit ces tests à la main, mais c'est un travail fastidieux. Récemment, nous avons commencé à utiliser l'intelligence artificielle, plus précisément les modèles de langage étendus (LLM), pour écrire ces tests à notre place. Considérez un LLM comme un robot super intelligent qui a lu presque tous les livres de cuisine du monde et peut rédiger de nouvelles recettes instantanément.

Cependant, il y a un piège. Bien que ces chefs IA soient excellents pour écrire l'histoire du test de dégustation, ils oublient souvent les « règles de la cuisine » (les règles du métier). Ils peuvent oublier de prendre les bons ingrédients (les imports), utiliser le mauvais type de poêle (les frameworks) ou essayer de cuisiner sans allumer le feu (un setup manquant). Dans le monde réel, si un test ne compile pas — c'est-à-dire qu'il ne peut même pas démarrer à cause de ces petites erreurs — il est inutile, peu importe la finesse de sa logique. Ce document explore pourquoi les tests générés par l'IA échouent souvent dans des cuisines réelles et désordonnées, et propose une nouvelle façon d'aider l'IA à réussir.

Le Problème : Le Chef IA qui oublie la Poêle

Les auteurs de ce document, une équipe de l'Université de Tianjin et de Huawei Cloud, ont remarqué quelque chose de frustrant lors de leur travail sur de grands projets logiciels industriels. Ils ont essayé d'utiliser les derniers outils d'IA pour écrire automatiquement des tests unitaires, et bien que l'IA puisse générer des idées de tests ingénieuses, les résultats étaient souvent un désastre en pratique.

Imaginez demander à un robot de construire un château en Lego. Le robot peut concevoir un design brillant pour les tours et les drapeaux, mais s'il oublie d'inclure la plaque de base ou s'il essaie d'utiliser une pièce provenant d'un autre ensemble qui ne s'adapte pas, tout l'édifice s'effondre. En termes de logiciel, l'IA échouait souvent à faire « compiler » les tests. Cela se produisait parce que le logiciel réel est comme une immense ville interconnectée. Un seul morceau de code (une « méthode focale ») peut dépendre de bibliothèques, d'autres fichiers et de frameworks spécifiques dont l'IA n'avait pas connaissance car elle ne regardait que la pièce de code spécifique qu'on lui avait demandé de tester.

Les chercheurs ont identifié trois raisons principales pour lesquelles l'IA échouait systématiquement :

1. Incohérence de contexte : L'IA devinait les règles de la cuisine (comme le framework de test à utiliser) au lieu de se les voir communiquer. Elle devinait les mauvais ingrédients, entraînant des erreurs immédiates.
2. Échafaudage fragile : L'IA essayait de construire toute la structure du test à partir de zéro, y compris la configuration et les imports. C'était comme demander au robot de construire à la fois la plaque de base et le château ; il se trompait souvent sur la plaque de base, faisant s'effondrer tout le château.
3. Réparations coûteuses : Lorsque le test échouait, la solution habituelle consistait à demander à l'IA d'essayer encore, et encore, et encore. C'était comme renvoyer le robot à la planche à dessin dix fois pour réparer une vis manquante. Cela prenait beaucoup de temps, consommait beaucoup de puissance de calcul (tokens) et l'IA faisait souvent la même erreur à nouveau.

La Solution : CATGen, l'Assistant de Cuisine Intelligent

Pour corriger cela, l'équipe a construit un nouveau flux de travail appelé CATGen. Au lieu de laisser l'IA tout deviner, ils ont décidé d'agir comme un gestionnaire de cuisine strict mais utile qui prépare parfaitement le poste de travail avant que le chef ne commence à cuisiner.

Leur approche comporte quatre étapes principales, qu'ils appellent un « flux de travail sensible au contexte » :

1. Rassembler le Contexte : Avant que l'IA n'écrive la moindre ligne de code, CATGen scanne l'ensemble du projet pour trouver les « ingrédients » nécessaires. Il examine les fichiers de construction pour voir quels frameworks de test (comme JUnit) et quelles bibliothèques de simulation (comme Mockito) sont utilisés. Il vérifie également quels autres fichiers le code sollicite. Cela garantit que l'IA sait exactement quels outils sont disponibles.
2. Construire le Squelette : Au lieu de demander à l'IA de construire toute la classe de test de zéro, CATGen construit d'abord un « squelette ». Considérez cela comme le pré-assemblage de la plaque de base et de la structure du château. Il utilise des règles strictes pour garantir que les imports, les noms de classes et les méthodes de configuration sont 100 % corrects. L'IA n'est alors sollicitée que pour remplir la « chair » du test — la logique réelle — à l'intérieur de cette structure pré-construite et sécurisée.
3. Combler les Lacunes : L'IA écrit maintenant les méthodes de test, mais comme elle travaille à l'intérieur d'un squelette parfait, elle est beaucoup moins susceptible de commettre des erreurs structurelles. Elle se concentre purement sur la logique du test.
4. Le Filet de Sécurité (Analyse Statique) : Si l'IA commet tout de même une petite erreur (comme un point-virgule manquant ou un nom de variable erroné), au lieu de demander à l'IA de réessayer, CATGen utilise un outil d'« analyse statique ». C'est comme un correcteur orthographique pour le code qui corrige instantanément les erreurs courantes en se basant sur les règles du projet. C'est rapide, déterministe et cela évite de perdre du temps à demander à l'IA de deviner à nouveau.

Les Résultats : Plus Rapide, Plus Intelligent et Réellement Fonctionnel

L'équipe a testé CATGen sur des projets industriels réels (qui sont très complexes) ainsi que sur un célèbre benchmark open-source appelé Defects4J. Ils l'ont comparé à six autres méthodes de pointe, incluant les outils traditionnels basés sur la recherche et d'autres approches d'IA.

Les résultats sont impressionnants. Dans le cadre industriel, CATGen a atteint un taux de réussite de compilation de 91,83 %. Cela signifie que sur 100 tests générés, plus de 91 fonctionnaient immédiatement. En comparaison, la deuxième meilleure méthode d'IA n'a réussi qu'environ 67 %, et l'outil traditionnel (EvoSuite) a atteint 75,80 %.

Mais il ne s'agissait pas seulement de fonctionnement ; il s'agissait aussi de qualité. CATGen couvrait plus de lignes de code (70,10 % de couverture de lignes) et plus de branches logiques (63,92 % de couverture de branches) que les autres méthodes. Le plus important encore, il était incroyablement efficace. Alors que d'autres méthodes prenaient des milliers de secondes et des millions de « tokens » (la monnaie de calcul de l'IA) pour générer et corriger des tests, CATGen a terminé l'ensemble du travail en seulement 1 836 secondes et a utilisé seulement 203 000 tokens. C'est une réduction massive de temps et de coût — environ 50 % à 80 % de moins que les autres méthodes.

Les chercheurs ont également réalisé une « étude d'ablation », qui consiste à démonter une machine pour voir quelle partie fait quoi. Ils ont découvert que si l'on supprimait l'étape du « squelette », le taux de réussite chutait considérablement. Si l'on supprimait l'étape de réparation par « analyse statique », le taux de réussite s'effondrait encore plus. Cela a prouvé que chaque partie de leur nouveau système était essentielle.

La Conclusion

La grande leçon de ce document est que faire fonctionner l'IA efficacement dans le monde réel ne consiste pas seulement à écrire un meilleur « prompt » (les instructions que vous donnez à l'IA). Il s'agit de construire un meilleur système autour de l'IA. En donnant à l'IA le bon contexte, en construisant une base solide pour son travail et en utilisant des outils non-IA rapides pour corriger les petites erreurs, nous pouvons rendre les tests générés par l'IA réellement utiles pour les développeurs.

Les auteurs suggèrent que pour que l'IA soit véritablement utile en ingénierie logicielle, nous devons cesser de la traiter comme une baguette magique qui résout tout toute seule. Au lieu de cela, nous devrions la traiter comme un composant puissant au sein d'un système plus large et bien conçu. Comme ils le disent, la génération de tests fiables dépend moins de l'« ingénierie de prompt » seule que d'un « support d'ingénierie systématique ». En fin de compte, CATGen montre que lorsqu'on donne au chef IA une cuisine appropriée et une recette claire, il peut concocter de très bons tests.