Première implémentation open source de TestGen-LLM de Meta

• L’article publié par Meta en février, « Automated Unit Test Improvement using Large Language Models at Meta », présente un outil appelé TestGen-LLM
• Cet outil vise à augmenter la couverture de test de manière entièrement automatisée, tout en garantissant une amélioration par rapport à la base de code existante
• Meta n’ayant pas publié le code de TestGen-LLM, il a été décidé de l’implémenter directement dans le cadre de l’outil open source Cover-Agent
• Sont partagés ici le processus d’implémentation, les constats réalisés et les difficultés rencontrées lors de l’utilisation de TestGen-LLM sur de vraies bases de code

Critères de la génération automatique de tests

• La génération automatique de tests avec l’IA générative n’est pas nouvelle
• La plupart des LLM sont performants pour générer du code et peuvent aussi produire des tests
• Le problème le plus fréquent rencontré par les développeurs lorsqu’ils génèrent des tests avec un LLM est que la majorité des tests produits ne fonctionnent pas ou n’apportent pas de valeur
• Pour surmonter cela, les auteurs de TestGen-LLM proposent les critères suivants pour les tests unitaires de régression :
  1. Le test compile-t-il et s’exécute-t-il correctement ?
  2. Le test augmente-t-il la couverture du code ?
• Tant que ces deux questions fondamentales n’ont pas de réponse positive, il n’y a aucune raison d’accepter ou même d’analyser les tests générés par le LLM
• Si ces critères sont remplis, une revue manuelle peut ensuite avoir lieu
  • Le test est-il bien écrit ?
  • Quelle valeur réelle ajoute-t-il ?
  • Répond-il à des exigences supplémentaires ?

Approche de TestGen-LLM et résultats rapportés

• TestGen-LLM (ainsi que Cover-Agent) fonctionne de manière entièrement headless
• L’outil génère d’abord un grand nombre de tests, puis filtre ceux qui ne se compilent pas ou ne s’exécutent pas, rejette ceux qui ne passent pas, et élimine ceux qui n’augmentent pas la couverture du code
• Dans des cas très contrôlés, le ratio entre les tests générés et ceux qui passent toutes les étapes est de 1:4 ; dans des scénarios réels, les auteurs de Meta rapportent un ratio de 1:20
• Après le processus automatisé, Meta laisse des relecteurs humains accepter ou rejeter les tests
• Les auteurs de l’article indiquent un ratio d’acceptation moyen de 1:2, avec un taux d’acceptation pouvant atteindre 73 % dans le meilleur des cas
• Comme décrit dans l’article, l’outil TestGen-LLM génère à chaque exécution un seul test, ajouté à une suite de tests existante écrite auparavant par un développeur expérimenté
• Il ne génère pas non plus nécessairement un test pour chaque suite de tests donnée

Implémentation de Cover-Agent

• Cover-Agent v0.1 est implémenté de la manière suivante :
  1. Réception des entrées utilisateur (fichier source à tester, suite de tests existante à améliorer, rapport de couverture, commandes de build et d’exécution de la suite de tests, objectif de couverture de code et nombre maximal d’itérations, contexte supplémentaire et options de prompt)
  2. Génération de tests supplémentaires dans le même style
  3. Validation de ces tests via l’environnement d’exécution (build et passage des tests)
  4. Vérification, à l’aide de métriques comme l’augmentation de la couverture, que les tests apportent bien de la valeur
  5. Mise à jour de la suite de tests existante et du rapport de couverture
  6. Répétition du processus jusqu’à ce que le code atteigne le critère visé (seuil de couverture atteint ou nombre maximal d’itérations atteint)

Problèmes rencontrés lors de l’implémentation et de l’évaluation de TestGen-LLM

• Dans les exemples présentés dans l’article, Kotlin est utilisé pour écrire les tests, un langage dans lequel les espaces ne sont pas significatifs
• En revanche, dans des langages comme Python, les tabulations et les espaces sont non seulement importants, mais indispensables au moteur d’analyse syntaxique
• Des modèles moins sophistiqués comme GPT 3.5 ne renvoient pas systématiquement du code correctement indenté, même avec des prompts explicites
• Un exemple typique de problème est celui des classes de test en Python, où chaque fonction de test doit être indentée
• Cela a dû être pris en compte tout au long du cycle de développement, ce qui a ajouté davantage de complexité autour des bibliothèques de prétraitement
• Il reste encore beaucoup à améliorer pour rendre Cover-Agent robuste dans ce type de scénario
• Une fonctionnalité a été ajoutée pour permettre à l’utilisateur de fournir au LLM des entrées ou instructions supplémentaires dans le flux Cover-Agent (option --additional-instructions)
• Cela permet aux développeurs de personnaliser Cover-Agent en fournissant des informations complémentaires spécifiques à leur projet
• Par exemple, ces instructions peuvent orienter Cover-Agent vers la création d’un ensemble de tests riche en cas limites pertinents
• En accord avec la tendance générale à une diffusion plus large du Retrieval-Augmented Generation (RAG) dans les applications d’IA, il a été constaté que disposer de davantage de contexte pour la génération de tests unitaires permet d’obtenir des tests de meilleure qualité et un meilleur taux de réussite
• Pour les utilisateurs souhaitant ajouter manuellement des bibliothèques supplémentaires ou des documents de conception textuels comme contexte pour le LLM afin d’améliorer le processus de génération de tests, l’option --included-files est proposée
• Les bases de code complexes nécessitant plusieurs itérations représentent un autre défi pour les LLM
• À mesure que des tests échoués (ou sans valeur ajoutée) sont générés, un schéma a commencé à apparaître : les mêmes tests non retenus sont proposés de façon répétée dans les itérations suivantes
• Pour résoudre ce problème, une section « failed tests » a été ajoutée au prompt afin de transmettre ce retour au LLM, de l’amener à générer des tests uniques et de l’empêcher de répéter des tests jugés inutilisables (par exemple cassés ou n’apportant pas assez de couverture)
• Un autre problème soulevé tout au long du processus est l’impossibilité d’ajouter des imports de bibliothèques lors de l’extension d’une suite de tests existante
• Les développeurs peuvent parfois adopter une approche trop étroite en n’utilisant qu’une seule manière d’aborder le framework de test dans le processus de génération
• Au-delà des nombreux frameworks de mocking, d’autres bibliothèques peuvent aussi contribuer à atteindre une meilleure couverture de test
• L’article sur TestGen-LLM (ainsi que Cover-Agent) ayant pour objectif d’étendre une suite de tests existante, une refonte complète de toute la classe de test sort du périmètre
• C’est une limite de l’extension de tests par rapport à la génération de tests, et il est prévu de la traiter dans de futures itérations
• Il est important de souligner que, dans l’approche de TestGen-LLM, chaque test nécessite une revue manuelle par le développeur avant qu’un test suivant ne soit proposé
• À l’inverse, Cover-Agent génère, valide et propose autant de tests que possible sans intervention manuelle pendant tout le processus, jusqu’à atteindre les exigences de couverture (ou s’arrêter au nombre maximal d’itérations)
• Il en résulte une approche peu intrusive de la génération automatique de tests, exécutée en arrière-plan avec l’aide de l’IA, afin que le développeur puisse examiner l’ensemble de la suite de tests une fois le processus terminé

Conclusion et plans futurs

• Beaucoup de personnes, moi y compris, attendent beaucoup de l’article et de l’outil TestGen-LLM, mais ce billet s’est volontairement concentré sur ses limites
• Nous sommes encore, selon moi, à l’ère des assistants IA, et non à celle de coéquipiers IA capables d’exécuter des workflows entièrement automatisés
• En même temps, un flux bien conçu peut aider les développeurs à générer automatiquement des candidats au test et à augmenter la couverture de code en beaucoup moins de temps, ce qui est ce qu’il est prévu de développer et de partager avec Cover-Agent
• Les méthodes de pointe liées au domaine de la génération de tests continueront d’être développées et intégrées au dépôt open source de Cover-Agent
• Toute personne intéressée par l’IA générative appliquée au testing est invitée à collaborer et à aider à étendre les capacités de Cover-Agent, avec l’espoir d’inspirer aussi les chercheurs à explorer de nouvelles techniques de génération de tests à l’aide de cet outil open source
• Une feuille de route de développement a été ajoutée au dépôt open source Cover-Agent sur GitHub, et il serait apprécié de voir des contributions selon cette roadmap ou selon vos propres idées
• La vision de Cover-Agent est, à terme, de s’exécuter automatiquement pour toutes les pull requests avant et après soumission, et de proposer automatiquement des améliorations de tests de régression vérifiées comme fonctionnelles et augmentant la couverture de code
• L’idée est d’imaginer Cover-Agent scanner automatiquement une base de code et ouvrir une PR avec une suite de tests
• Exploitons l’IA pour traiter plus efficacement les tâches que nous n’aimons pas faire !