💻 computer science

Reproduction Test Generation for Java SWE Issues

Cet article comble le manque d'outils de génération de tests de reproduction pour Java en présentant TDD-Bench-Java, le premier benchmark pour cette tâche comprenant 250 instances issues de dépôts open-source, et e-Otter++, une solution adaptée qui démontre des performances élevées à la fois sur ce benchmark et sur un jeu de données industriel propriétaire.

Auteurs originaux : Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Publié 2026-05-07

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes un détective logiciel travaillant pour une immense entreprise. Un utilisateur signale un bug : « Hé, quand je clique sur ce bouton, l'application plante ! » Avant de pouvoir corriger le code, vous devez prouver que le bug existe réellement. Vous écrivez un petit script de test automatisé qui tente de cliquer sur ce bouton. Si le script plante, vous avez confirmé le bug. Une fois le code corrigé, vous exécutez à nouveau le script ; s'il fonctionne maintenant parfaitement, vous savez que la correction est réelle.

Ce papier traite de l'enseignement à une IA d'écrire automatiquement ces scripts spécifiques de « chasse aux bugs », mais avec une particularité : elle le fait pour Java, un langage de programmation utilisé par d'énormes entreprises, alors que les outils d'IA précédents fonctionnaient principalement bien uniquement pour Python.

Voici la décomposition de leur travail utilisant quelques analogies du quotidien :

1. Le Problème : L'absence de « Chasseur de bugs »

Dans le monde du logiciel, écrire ces tests de chasse aux bugs est fastidieux et souvent sauté. Récemment, l'IA est devenue bonne pour les écrire pour Python (un langage populaire pour les startups et la science des données). Mais Java est la « machinerie lourde » du monde corporatif (banques, compagnies aériennes, grandes technologies). L'IA peinait avec Java car il est plus rigide et complexe.

Les auteurs disent : « Nous avons besoin d'un meilleur moyen d'enseigner à l'IA à chasser les bugs en Java. »

2. La Nouvelle Carte : TDD-Bench-Java

Pour entraîner et tester leur IA, ils avaient besoin d'une carte. Ils ont créé un nouveau benchmark appelé TDD-Bench-Java.

L'Analogie : Pensez-y comme à une immense « Salle de sport pour l'IA ». Elle contient 250 rapports de bugs réels provenant de projets Java open-source célèbres. Chaque « séance d'entraînement » consiste en une description de bug et le code avant la correction. Le travail de l'IA est d'écrire un test qui échoue sur le code cassé et réussit sur le code corrigé.
Pourquoi c'est important : Avant cela, il n'existait pas de méthode standardisée pour voir si l'IA pouvait réellement faire cela pour Java. Ce benchmark est le premier de son genre.

3. La Solution : e-Otter++ (Le Détective Intelligent)

Ils ont pris un détective IA existant nommé e-Otter (qui était excellent pour Python) et lui ont donné une métamorphose Java, appelant la nouvelle version e-Otter++.

Voici comment ce détective IA résout une affaire, étape par étape :

Étape 1 : Le Localisateur (Trouver la scène du crime)
L'IA examine le rapport de bug et la base de code massive. Elle doit deviner où se cache le problème. C'est comme un détective regardant une carte de la ville et une description vague d'un crime pour deviner quel bâtiment et quelle pièce spécifiques enquêter.
- La Particularité Java : En Java, vous devez souvent créer un tout nouveau fichier pour un test. L'IA doit déterminer exactement où placer ce nouveau fichier pour ne pas briser la structure du bâtiment.
Étape 2 : Le Contextualisateur (Rassembler les indices)
Une fois qu'elle connaît l'emplacement, elle rassemble les bons outils (importations) et met en place la scène (noms de packages). C'est comme un détective s'assurant qu'il a le bon badge et le bon plan d'étage avant d'entrer dans la pièce.
Étape 3 : Le Générateur de Test Initial (Faire la première tentative)
L'IA écrit un brouillon de script de test. C'est une ébauche grossière.
Étape 4 : Le Raffineur (La boucle de rétroaction)
C'est le secret. L'IA exécute son propre test sur le code cassé.
- Scénario A : Le test plante, mais pour la mauvaise raison (par exemple, il a planté à cause d'une faute de frappe, pas du bug).
- La Correction : L'IA examine le message d'erreur, réalise son erreur, réécrit le test et réessaie. Elle fait cela jusqu'à 10 fois, apprenant de chaque échec, jusqu'à ce qu'elle trouve un test qui plante exactement à cause du bug signalé.
Étape 5 : Prompting Hétérogène (Poser la même question de 6 manières)
Pour s'assurer de ne pas manquer la solution, l'IA réécrit le rapport de bug de six manières différentes (en le simplifiant, en retirant le code confus, en ajoutant un « indice », etc.) et génère six candidats de test différents. C'est comme demander à six détectives différents de résoudre la même affaire en utilisant des angles différents.
Étape 6 : Le Sélecteur (Choisir le gagnant)
Enfin, une IA « Juge » examine les six candidats et choisit le seul meilleur test à soumettre.

4. Les Résultats : À quel point est-ce bien ?

Sur la Salle de sport publique (TDD-Bench-Java) : L'IA a réussi environ 44 % à 46 % du temps. Cela signifie qu'elle a écrit avec succès un test qui a attrapé le bug et confirmé la correction dans près de la moitié des cas. Cela est considéré comme un résultat solide pour une tâche aussi difficile.
Sur le « Monde Réel » (Données Propriétaires) : Les auteurs ont également testé cela sur 150 bugs provenant de leur propre entreprise privée (IBM).
- Le Défi : Ces bugs étaient plus difficiles. Les descriptions étaient plus courtes, plus vagues, et impliquaient souvent la création de tout nouveaux fichiers qui n'existaient pas encore.
- Le Résultat : Sans aide, l'IA n'a réussi que 4 % du temps.
- La Correction : Lorsqu'ils ont donné à l'IA un « indice » (lui indiquant les noms des nouveaux fichiers qu'elle devait créer), le taux de réussite a bondi à 20 %.

5. La Conclusion

Le papier conclut que, bien que l'IA s'améliore dans l'écriture de tests de chasse aux bugs pour Java, elle peine toujours face à la réalité désordonnée et vague des logiciels d'entreprise par rapport aux données plus propres trouvées dans les projets open-source.

En bref : Ils ont construit un nouveau terrain d'entraînement (TDD-Bench-Java) et un détective plus intelligent (e-Otter++) qui peut maintenant chasser les bugs dans le code Java. Cela fonctionne bien sur des problèmes standards mais a encore besoin d'un peu d'aide humaine (indices) lorsque les indices sont vagues ou que le code est tout nouveau.

Résumé Technique : Génération de Tests de Reproduction pour les Problèmes SWE en Java

Énoncé du Problème

L'article traite de l'écart critique dans l'ingénierie logicielle (SWE) automatisée pour Java : la génération de tests de reproduction. Un test de reproduction est défini comme un test qui échoue sur la base de code actuelle (confirmant la présence d'un problème) et réussit après la correction du problème (confirmant son absence). Bien que des avancées récentes aient produit des benchmarks et des solutions pour Python, Java reste sous-desservi malgré sa domination dans le logiciel d'entreprise. Les outils existants axés sur Java manquent soit de capacités de localisation de défauts, soit s'appuient sur des variantes de problèmes simplifiées, ou souffrent de contamination des ensembles de données et de surajustement. De plus, les bogues Java d'entreprise diffèrent souvent dans leur distribution et leur complexité des bogues Python open-source, nécessitant des approches spécialisées tenant compte du système de types statique de Java et de sa nature orientée objet.

Méthodologie

Les auteurs proposent e-Otter++ pour Java, une adaptation d'un générateur de tests de reproduction Python de l'état de l'art. La méthodologie est un pipeline multi-étapes conçu pour gérer la complexité au niveau du dépôt sans nécessiter l'accès au code de correction ( $c_{new}$ ) pendant la génération.

1. Architecture du Pipeline

Le flux de travail se compose de quatre composants principaux :

Localisateur : Identifie les « fonctions focales » (susceptibles d'être modifiées) et les tests de régression associés. Contrairement à la version Python qui séparait ces tâches, la version Java les fusionne en une seule étape pour gérer la fréquence plus élevée de nouveaux fichiers de test dans les projets Java. Il utilise un processus en trois étapes avec un LLM : sélection des fichiers pertinents par nom, sélection des fonctions par nom, et filtrage final basé sur les corps de fonction.
Contextualisateur : Construit l'échafaudage nécessaire pour un nouveau fichier de test, ce qui est courant en Java. Il détermine le nom de package correct, les imports et le chemin du fichier en interrogeant le dépôt et en sélectionnant parmi les options existantes pour minimiser les hallucinations.
Générateur de Test Initial : Génère un candidat de test initial ( $t_{ot}$ ) sous forme d'une nouvelle classe dans un nouveau fichier, sollicité avec la description du problème et le contexte localisé.
Raffineur : Améliore itérativement le test en utilisant des retours d'exécution. Il exécute le test sur l'ancien code ( $c_{old}$ ), analyse les journaux via un critique basé sur un LLM, et réécrit le test s'il échoue pour la mauvaise raison. Cette boucle s'exécute jusqu'à 10 fois, accumulant les modifications pour prévenir les erreurs répétitives.

2. Mise à l'échelle de l'Inférence par Prompting Hétérogène

Pour augmenter la diversité des candidats de test, le système emploie un prompting hétérogène plutôt qu'un échantillonnage basé sur la température. La description du problème est réécrite en six variantes distinctes (morphs) :

Standard : Réécriture dans un format structuré.
Simple : Suppression du jargon et simplification du texte.
dropCode : Suppression des extraits de code potentiellement trompeurs.
initTest : Incorporation d'un test initial généré dans le prompt.
initPatch : Incorporation d'un correctif de code suggéré dans le prompt.
Défaut : Utilisation de la description originale du problème.

Un Sélecteur de Test évalue ensuite les six candidats résultants (ainsi que leurs journaux d'exécution) et sélectionne le seul meilleur test pour soumission.

Contributions Clés

TDD-Bench-Java : Le premier benchmark au niveau du dépôt spécifiquement pour la génération de tests de reproduction en Java. Il comprend 250 instances provenant de dépôts open-source populaires (par exemple, Trino, Jackson, RocketMQ), filtrées pour garantir un comportement « échec-vers-réussite ». L'ensemble de données inclut divers outils de construction (Maven, Gradle) et structures de projet.
e-Otter++ pour Java : Une solution robuste adaptée des flux de travail Python, atteignant des performances élevées sur le nouveau benchmark. C'est la première solution complète pour la génération de tests de reproduction Java au niveau du dépôt incluant la localisation de défauts.
Évaluation Industrielle Propriétaire : L'article évalue le système sur un ensemble de données propriétaire exempt de contamination de 150 problèmes issus d'un projet Java interne d'IBM. Cela fournit des perspectives sur les défis de l'application de ces modèles au code d'entreprise réel, qui diffère souvent considérablement des données open-source.

Résultats

Benchmark Public (TDD-Bench-Java)

En utilisant les modèles Claude-Sonnet-4.5 et GPT-5.2, e-Otter++ a obtenu :

Un taux de « échec-vers-réussite » de 43,6 % avec Claude-Sonnet-4.5.
Un taux de « échec-vers-réussite » de 46,4 % avec GPT-5.2.

Constats Clés :

Impact du Raffinement : L'étape de raffinement (e-Otter) a considérablement amélioré les performances par rapport au générateur initial (Otter), avec des améliorations relatives allant de 26,2 % à 64,3 % selon le modèle et le morph.
Prompting Hétérogène : L'utilisation de six morphs a augmenté le taux de « échec-vers-réussite » à N=6 (au moins un candidat réussit) de plus de 32 % par rapport aux approches à variante unique.
Significativité Statistique : Les tests de McNemar ont confirmé que les améliorations d'Otter à e-Otter étaient statistiquement significatives ( $p < 0,01$ ).

Résultats sur l'Ensemble de Données Propriétaire

Les performances sur l'ensemble de données interne d'IBM étaient plus faibles, soulignant la difficulté du code d'entreprise :

Performance par Défaut : Avec les descriptions de problèmes par défaut, le taux de « échec-vers-réussite » était de seulement 4 % (6/150).
Avec Indices : Lorsque le système a reçu des « indices » (nouveaux noms de classes et signatures de fonctions dérivés du correctif de code), le taux s'est amélioré à 20 % (30/150).
Caractéristiques des Données : Les problèmes propriétaires étaient plus courts, manquaient d'extraits de code et impliquaient des correctifs de code significativement plus grands (moyenne de 362 lignes contre 55 lignes dans les données publiques). De plus, 84 % des problèmes propriétaires étaient des demandes de fonctionnalités plutôt que des corrections de bogues, introduisant souvent de nouveaux fichiers que les modèles peinent à anticiper.

Signification et Revendications

L'article revendique une contribution significative au domaine en :

Combler le Fossé Linguistique : Fournissant le premier benchmark et la première solution dédiés à Java, une langue critique pour le logiciel d'entreprise mais précédemment négligée dans la recherche sur la génération de tests de reproduction.
Pertinence Industrielle : Allant au-delà des benchmarks open-source pour évaluer les performances sur des données propriétaires, révélant que si les modèles performent bien sur des données publiques curatées, ils font face à des défis substantiels avec le « bruit » et la complexité des problèmes d'entreprise réels (par exemple, descriptions courtes, génération de nouveaux fichiers).
Rigueur Méthodologique : Démontrant que la mise à l'échelle de l'inférence par prompting hétérogène et le raffinement piloté par l'exécution sont des stratégies efficaces pour Java, même lorsque le système de types statique introduit des erreurs de temps de compilation qui diffèrent des erreurs d'exécution de Python.

Les auteurs concluent que si les approches actuelles basées sur les LLM montrent des promesses, apporter un diagnostic et une validation fiables au développement logiciel Java nécessite davantage d'innovation, en particulier dans la gestion des problèmes mal spécifiés et la génération de contextes précis pour les nouvelles structures de code.