TestMap: Evidence Infrastructure for Foundation-Model-Assisted Test Generation

Résumé Technique : TestMap – Infrastructure de Preuves pour la Génération de Tests Assistée par Modèles de Fondation

Énoncé du Problème
Les modèles de fondation (FM) sont de plus en plus capables de générer des tests unitaires plausibles ; cependant, déterminer leur exactitude, leur utilité, leur maintenabilité et leur valeur d'intégration reste un défi important. Le problème central est un problème de « validation récursive » : les tests générés sont à la fois des artefacts de code et des artefacts de validation. Ils doivent être validés avant de pouvoir être jugés dignes de confiance pour valider le système sous test. Actuellement, le processus de validation est fragmenté entre des outils disparates (systèmes de construction, exécuteurs de tests, outils de couverture, outils de mutation, analyseurs statiques), qui ne rapportent souvent que des résultats agrégés plutôt que de lier les preuves à chaque candidat de test individuel. De plus, les approches existantes rejettent fréquemment les candidats échoués ou intermédiaires, perdant ainsi des données précieuses concernant les limitations des modèles, le manque de contexte ou les défauts potentiels dans le système sous test.

Méthodologie : L'Infrastructure TestMap
Le document présente TestMap, un prototype d'infrastructure open-source conçu pour automatiser la génération et l'évaluation de tests assistés par FM avec preuves à l'appui, ciblant spécifiquement les dépôts C#/.NET. TestMap traite les tests générés comme des « candidats » plutôt que comme des réponses définitives, enregistrant l'intégralité de leur cycle de vie.

Le système fonctionne via un pipeline structuré :

1. Ingestion du Dépôt et Analyse Statique : TestMap clone un dépôt cible, utilise les API Roslyn pour analyser la solution et effectue une analyse statique pour cartographier le code source, les dépendances et les structures de tests. Il collecte les métriques de code et détecte les « odeurs » de tests (en utilisant une version personnalisée de xNose).
2. Exécution de Référence (Baseline) : Avant la génération, la suite de tests existante est exécutée pour établir une référence pour la couverture, les scores de mutation et les résultats d'exécution.
3. Sélection de la Cible et Construction du Contexte : Les cibles de génération (ex: méthodes sources) sont sélectionnées selon des critères configurables tels que les lignes non couvertes, les mutants survivants ou les tests apparentés. Un « paquet de preuves » est construit, incluant le code cible, les tests associés, les lacunes de couverture et les conventions du framework.
4. Génération Guidée par le Modèle : TestMap emploie un pipeline de génération décomposé (inspiré de RUG) plutôt qu'une génération par prompt unique. Il fragmente la tâche en étapes de planification (planification de scénarios, nommage de méthodes, arrangement, planification des entrées, planification des actions, planification des assertions), suivies de la synthèse finale. Il supporte différents modes de contexte (ex: NoHistory vs ChainedHistory) et des budgets pass@k.
5. Validation et Réparation : Les candidats générés subissent une validation pré-exécution (extraction de syntaxe, insertion, diagnostics du compilateur) et une validation post-exécution (construction, exécution, couverture, mutation). Les candidats échoués ne sont pas jetés ; ils sont conservés avec leurs données de diagnostic. Si activé, une boucle de réparation utilise les erreurs de compilation, les journaux d'exécution et les échecs d'assertions pour inciter le modèle à des révisions.
6. Persistance des Preuves : Tous les artefacts — y compris les prompts, les réponses du modèle, les journaux de construction, les résultats d'exécution, les deltas de couverture, les résultats de mutation et l'historique des réparations — sont persistés dans une base de données SQLite. Cela permet une analyse granulaire de chaque candidat et une comparaison agrégée des stratégies.

Principales Contributions
Le document présente les contributions suivantes :

1. Cadrage du Problème : Il définit la génération de tests assistée par FM comme un problème de validation récursive où les tests générés doivent être validés avant de servir de preuve.
2. Prototype TestMap : Il introduit une infrastructure de preuves open-source qui automatise l'analyse de dépôt, la validation de candidats, la collecte de preuves, le suivi de la réparation et la journalisation des expériences.
3. Préservation du Cycle de Vie : Le système préserve l'intégralité du cycle de vie des candidats, incluant les résultats échoués, réparés, à faible impact et positifs en termes de preuves, permettant l'étude des résultats intermédiaires.
4. Expérimentations Spécifiques aux Dépôts : Il facilite les expériences comparant les modèles, les prompts, les stratégies de génération et les flux de travail de réparation sur des bases de code concrètes, allant au-delà des benchmarks standardisés.
5. Modèle de Preuve : Il définit un modèle de preuve structuré reliant les candidats au contexte du dépôt, aux paramètres de génération, aux résultats d'exécution et aux indicateurs de qualité.

Résultats et Constatations
Le document ne présente pas une étude empirique à grande échelle avec des mesures de performance quantitatives (ex: « TestMap a amélioré la couverture de X% »). Au lieu de cela, les « résultats » consistent en la démonstration de la capacité de l'infrastructure à :

• Ingérer et analyser avec succès de réels dépôts C#/.NET.
• Exécuter le pipeline complet de génération à la validation, incluant la gestion des échecs de construction et des erreurs d'exécution.
• Persister des historiques détaillés de candidats, distinguant les résultats ValidationFailed, Validated, ValidatedLowImpact, et ValidatedEvidencePositive.
• Supporter des comparaisons de stratégies de génération spécifiques aux dépôts (ex: prompting naïf vs prompting piloté par les métriques).

Les auteurs notent que l'infrastructure révèle que les tests générés nécessitent souvent une réparation et que les candidats échoués fournissent des preuves critiques concernant la qualité de l'oracle, les lacunes de contexte et les inefficacités de la chaîne d'outils.

Signification et Revendications
Le document affirme que TestMap répond à un manque critique d'infrastructure en génie logiciel. Sa signification réside dans le passage d'une simple production de tests exécutables vers la création de tests générés observables, reproductibles et comparables.

• Au-delà des Benchmarks : TestMap complète les benchmarks standardisés en fournissant des preuves sur la manière dont la génération assistée par FM se comporte sous les contraintes réelles d'un dépôt spécifique (systèmes de construction, dépendances, styles de tests existants).
• Preuve pour la Prise de Décision : En préservant les candidats échoués et réparés, l'outil soutient la revue par les développeurs et l'analyse empirique, aidant à distinguer les limitations du modèle, les problèmes de la chaîne d'outils et les défauts réels du système.
• Direction Future : Les auteurs concluent que l'avenir des tests assistés par FM nécessite une infrastructure qui non seulement génère des tests, mais fournit également les preuves nécessaires pour décider si ces tests sont utiles, maintenables et dignes de confiance. TestMap est présenté comme une étape vers cette infrastructure de preuves, reconnaissant des défis ouverts tels que la qualité des assertions, la fragilité (flakiness), l'attribution des métriques et l'acceptation par les développeurs.

Le document maintient un ton modeste, précisant explicitement que l'actuel prototype ne traite pas directement des décisions des développeurs ni ne mesure l'amélioration de la calibration de la confiance, mais fournit l'infrastructure de données nécessaire à de telles études futures.