Heterogeneous Prompting and Execution Feedback for SWE Issue Test Generation and Selection

Résumé Technique : Prompting Hétérogène et Feedback d'Exécution pour la Génération et la Sélection de Tests de Problèmes SWE

Énoncé du Problème
Les problèmes de génie logiciel (SWE), qui décrivent des bugs ou des fonctionnalités manquantes, sont souvent accompagnés de descriptions informelles manquant de tests de reproduction automatisés. L'absence de tels tests entrave la vérification des problèmes et l'acceptation des correctifs de code. Le défi spécifique abordé dans cet article est la génération automatique de tests de reproduction « fail-to-pass » ($F \to P$) directement à partir des descriptions de problèmes et du code source existant (pré-correctif) ($c_{old}$), sans accès au correctif de code résolutif ($c_{new}$). Un test $F \to P$ valide doit échouer lors de l'exécution sur $c_{old}$ (reproduisant le problème) et réussir lors de l'exécution sur $c_{new}$ (confirmant la correction). Cette tâche est difficile car les descriptions de problèmes sont informelles et le code cible pour lequel le test doit réussir n'existe pas encore.

Méthodologie : e-Otter++
Les auteurs introduisent e-Otter++, un système qui étend le cadre de travail précédent, Otter++. Le système fonctionne via trois composantes principales : un générateur de tests, un générateur de correctifs de code et un sélecteur de tests.

1. Génération de Tests avec Prompting Hétérogène :
   Au lieu de s'appuyer uniquement sur l'augmentation des températures de décodage des LLM pour générer des candidats diversifiés (une pratique courante qui manque souvent de diversité), e-Otter++ emploie un prompting hétérogène. Cela implique deux variations systématiques :

   • Morphing de la Description du Problème : Un LLM réécrit la description originale du problème de cinq manières distinctes avant la génération du test : standard (formatage), simple (simplification du jargon), dropCode (suppression de fragments de code potentiellement trompeurs), initTest (incorporation d'un test initial) et initPatch (incorporation d'une proposition de correctif initiale).
   • Masques de Contexte : Le prompt de génération de test est modifié pour inclure ou exclure des contextes de localisation spécifiques (par exemple, les sorties du planificateur, la localisation du test, la localisation du correctif), créant ainsi cinq variations de prompts distinctes.
     En combinant ces éléments, le système génère un ensemble diversifié de 10 tests candidats par problème.

2. Réparation de Tests Augmentée par l'Exécution :
   Les tests candidats générés sont exécutés sur $c_{old}$. Bien qu'ils soient censés échouer, ils peuvent échouer pour de mauvaises raisons (par exemple, des erreurs de syntaxe ou des exceptions non liées) plutôt que de reproduire le problème spécifique décrit. e-Otter++ introduit un mécanisme de critique :

   • Un LLM analyse la description du problème et le journal d'exécution pour déterminer si le test échoue pour la « bonne raison ».
   • Si l'échec est incorrect, le critique identifie le contexte nécessaire (par exemple, des lignes de code buguées spécifiques, des fragments de code pertinents ou des signatures de fonctions) et augmente le prompt de réparation.
   • Le système répare de manière itérative le test (jusqu'à 10 tentatives) en utilisant ce contexte enrichi jusqu'à ce que le test échoue pour la raison correcte ou que la limite d'itération soit atteinte.

3. Sélection de Tests via des Correctifs de Substitution :
   Puisque $c_{new}$ est indisponible, e-Otter++ ne peut pas vérifier directement si un test réussit sur le véritable correctif. Pour résoudre cela, le système utilise Agentless pour générer 40 correctifs de code candidats (substituts pour $c_{new}$) et les filtre pour n'en garder que les 5 plus fréquents.

   • Le sélecteur de tests exécute les tests candidats sur ces correctifs de substitution.
   • Les tests qui sont $F \to P$ sur les correctifs de substitution sont prioritaires.
   • Un sélecteur basé sur des règles classifie les échecs (échecs d'assertions vs erreurs) et utilise la couverture de code (la proportion de lignes ajoutées/supprimées par le correctif que le test couvre) comme critère de départage pour sélectionner le test final unique.

Contributions Clés
L'article apporte trois contributions novatrices :

1. Réparation de Tests Augmentée par l'Exécution : Une méthode pour augmenter la correction des tests en utilisant le feedback d'exécution pour récupérer le code lié et augmenter le prompt de réparation, garantissant que les tests échouent pour les raisons spécifiées dans le problème.
2. Prompting Hétérogène pour la Diversité : Augmenter la diversité des candidats de tests grâce aux morphings de description de problèmes et aux masques de contexte, plutôt que de compter uniquement sur l'échantillonnage à haute température.
3. Sélection basée sur des Correctifs de Substitution : Une technique pour sélectionner le test final en utilisant le feedback d'exécution de correctifs de code imparfaits, générés comme proxy du correctif de vérité terrain.

Résultats
Le système a été évalué sur TDD-Bench Verified (449 échantillons) et SWT-bench Lite (276 échantillons), tous deux dérivés de SWE-bench.

• Performance : e-Otter++ a atteint un taux de Fail-to-Pass ($F \to P$) de pointe de 63,0 % sur TDD-Bench Verified et 52,5 % sur SWT-bench Lite (en utilisant le modèle Claude-3.7-Sonnet). Cela surpasse de manière significative les meilleurs résultats publiés précédents (Otter++ à 37,0 % et 29,0 %, respectivement).
• Efficacité des Composantes :
  • La réparation augmentée par l'exécution a amélioré les taux $F \to P$ de 11,1 % à 74,3 % selon les différentes configurations.
  • Le prompting hétérogène (morphs + masques) a augmenté le $F \to P@N$ (taux d'au moins un test réussi parmi $N$ candidats) de plus de 13 % par rapport à l'utilisation des masques seuls.
  • L'utilisation de correctifs de code générés comme pré-filtre pour la sélection de tests a fourni un gain de performance significatif (par exemple, une augmentation de 32,9 % du $F \to P$ sur TDD-Bench Verified).
• Généralisabilité : L'approche a été validée sur SWE-rebench, un benchmark sans contamination, où elle a amélioré le taux $F \to P$ de 75 % par rapport au système de base Otter, démontrant une robustesse face à la contamination des données.
• Utilité de Validation : Il a été démontré que les tests générés valident efficacement les correctifs de code d'autres agents SWE, améliorant considérablement la précision des solutions proposées par les systèmes leaders du classement.

Signification et Revendications
Les auteurs affirment que e-Otter++ représente un bond substantiel vers l'état de l'art pour la génération de tests de reproduction à partir de problèmes SWE. L'article soutient que la combinaison du prompting hétérogène et du feedback d'exécution — spécifiquement l'utilisation novatrice de correctifs de substitution pour la sélection et de la réparation augmentée par le contexte — surmonte les limites des méthodes précédentes qui peinaient avec la diversité des tests et l'absence de base de code cible pour la vérification.

Le travail vise à ancrer la pratique du Développement Piloté par les Tests (TDD) en automatisant la création fastidieuse de tests de reproduction, aidant ainsi les ingénieurs humains et les agents de génie logiciel automatisés dans la résolution de problèmes et l'assurance qualité à long terme. Les auteurs restent modestes quant à la portée du système, notant qu'il traite actuellement des fichiers de test uniques et qu'il est principalement évalué sur Python, mais soulignent que les améliorations relatives suggèrent que les techniques sont efficaces même sur des ensembles de données diversifiés et non contaminés.