Meta améliore les tests unitaires automatisés avec les LLM

TestGen-LLM de Meta pour améliorer les tests unitaires automatisés

• L'outil TestGen-LLM, développé par Meta, utilise des modèles de langage de grande taille (LLM) pour améliorer automatiquement les tests existants rédigés par des humains.
• Les classes de test générées par TestGen-LLM passent avec succès une série de filtres qui garantissent une amélioration mesurable par rapport à la suite de tests d'origine, ce qui permet de résoudre le problème des hallucinations des LLM.
• L'article décrit le déploiement de TestGen-LLM lors des test-a-thons pour les plateformes Instagram et Facebook de Meta.

Performances de TestGen-LLM

• Lors de l'évaluation sur les produits Reels et Stories d'Instagram, 75 % des cas de test de TestGen-LLM ont été compilés correctement, 57 % ont réussi de manière fiable, et 25 % ont augmenté la couverture.
• Lors des test-a-thons Instagram et Facebook de Meta, TestGen-LLM a amélioré 11,5 % de toutes les classes concernées, et les ingénieurs logiciels de Meta ont accepté 73 % des recommandations pour un déploiement en production.
• Il s'agit du premier rapport à l'échelle industrielle portant sur du code généré par des LLM bénéficiant de ces garanties d'amélioration du code.

Opinion de GN⁺

• TestGen-LLM est un outil qui pourrait révolutionner l'automatisation et l'amélioration de la qualité des tests logiciels, ayant réussi à améliorer des tests existants grâce à des modèles de langage de grande taille.
• L'outil contribue de manière significative à la communauté de l'ingénierie logicielle en augmentant la couverture de tests dans un environnement industriel réel et en générant des cas de test fiables.
• Les déploiements réussis de TestGen-LLM dans les test-a-thons de Meta montrent son potentiel d'intégration dans le développement de produits réels, ce qui pourrait améliorer l'efficacité et la stabilité du développement logiciel.

[GN⁺]

Avis sur Hacker News

• Dans une grande compagnie d’assurance, les responsables ont fixé un objectif de couverture de tests de 80 % sur l’ensemble de la base de code. Les développeurs ont donc commencé à écrire des tests unitaires basiques pour les getters et setters des DTO Java afin d’atteindre cet objectif. En tant que jeune développeur, cette expérience m’a montré qu’un focus sur les KPI peut inciter à des comportements qui ne correspondent pas à l’objectif visé. Quelques scénarios de tests E2E bien conçus auraient sans doute eu un meilleur impact sur la qualité logicielle.
• Le problème des tests générés par des LLM est qu’ils ont tendance à « valider » un comportement buggué, et cela peut être particulièrement vrai quand la couverture de la base de code est faible. Lorsqu’on écrit des tests à la main, il y a quelqu’un qui peut déterminer si c’est le système qui est stupide ou si le test est incorrect. A minima, ces tests devraient être séparés dans un dossier dédié et traités avec un niveau de suspicion approprié.
• Si l’on lit le PDF, cela semble viser essentiellement la production de tests qui passent de manière répétée, donc sans comportements capricieux. Le but principal est de créer une suite de tests de régression qui fige le comportement du code existant. Cela ne remplace pas les tests écrits par les développeurs, qui, eux, sont censés connaître les exigences fonctionnelles.
• Il y a environ 20 ans, dans une entreprise où j’ai travaillé, j’ai testé AgitarOne. Il promettait d’aider à explorer le comportement du code Java en générant automatiquement des cas de test. Mais Agitar pouvait aussi générer automatiquement des tests qui passent, réutilisables comme suite de régression. Personnellement, je ne l’aimais pas. Les responsables pensaient que la qualité s’améliorait puisque la couverture augmentait. Je me demande à quel point l’approche LLM est meilleure que celle d’Agitar.
• L’écriture de tests est généralement un excellent moyen d’évaluer la qualité du code. Si les tests sont complexes ou si la couverture est difficile à atteindre, il y a de fortes chances que le code ciblé ait besoin d’améliorations.
• unlogged.io a longtemps concentré ses efforts sur la génération automatique de tests JUnit. Cette approche n’a pas réussi pour plusieurs raisons : 1) de nombreux tests générés que les développeurs ne veulent pas maintenir, 2) des tests générés qui ne simulent pas les scénarios du monde réel, 3) la couverture de code comme indicateur de vanité. Aujourd’hui, ils se concentrent plutôt sur la fourniture de tests de replay no-code qui simulent tous les scénarios de production uniques. Pour rappel, je suis le fondateur d’unlogged.io.
• A contrario, j’aimerais m’y prendre autrement : fournir les critères d’acceptation, générer des tests qui les valident, puis n’autoriser la génération que du code qui fait passer ces tests. Avec Copilot, on peut parfois y parvenir de manière limitée, mais je me demande pourquoi personne ne se concentre vraiment sur cette approche.
• TestGen-LLM est une création étrange. Je pense qu’il peut être utilisé dans une première étape de refactoring ou de réécriture, mais l’insistance du papier sur la couverture de code paraît totalement tordue. Si une organisation a déjà les idées un peu troublées et exige déjà une couverture élevée, cela peut être bien, mais TestGen-LLM n’améliorera en rien le code du projet et augmentera la friction associée à la mise en œuvre des améliorations réelles. En filtrant les déchets des LLM via les erreurs du compilateur et les tests échoués, TestGen-LLM générerait bien mieux des tests de cas limites susceptibles de passer ou non. Je soupçonne qu’ils sont amateurs comme le reste du code généré par LLM que j’ai vu, car le papier ne propose aucun exemple de tests générés.
• Je me demande quel sera à l’avenir le coût de maintenance d’un gigantesque corpus de tests générés automatiquement. Il faut fournir une méthode automatisée non seulement pour générer des cas, mais aussi pour les mettre à jour.
• Il est intéressant d’admettre que des employés de Meta aient publié un papier de 12 pages pour promouvoir l’IA pour les développeurs. Ils ont même utilisé des diagrammes de Sankey. Je me trompe peut-être, mais s’il est question de présenter ça ainsi, des informations reproductibles devraient être fournies. Meta a besoin de données pour apprendre. C’est sans doute pourquoi ils ont pu publier quelque chose.
• Lors de l’évaluation des produits Reels et Stories d’Instagram, 75 % des cas de test de TestGen-LLM étaient correctement construits, 57 % passaient de manière fiable et 25 % augmentaient la couverture. Le résultat ne me semble pas très bon.