Résumé Technique : MocklessTester

Énoncé du Problème

Bien que les Modèles de Langage (LLM) aient démontré leur potentiel pour la génération automatisée de tests, les approches existantes pour Java reposent principalement sur des frameworks de simulation (mocking) (par exemple, Mockito) pour isoler la méthode à tester (MUT) de ses dépendances. Cette dépendance introduit deux limitations fondamentales :

1. Couverture Superficielle : Les tests simulés exercent la MUT de manière isolée, laissant le comportement réel des classes de dépendances non testé.
2. Fragilité des Simulations : Les tests deviennent étroitement couplés à des comportements d'API supposés, échouant lorsque les dépendances évoluent, même si le comportement réel reste compatible.

Le test sans simulation (mockless), qui instancie et exécute de véritables dépendances, offre une solution mais fait face à des défis significatifs. La génération de tests valides sans simulation exige une adhésion stricte aux contraintes du langage, une instanciation correcte des objets et des séquences d'appels d'API valides. Les approches actuelles basées sur les LLM peinent ici en raison de deux causes racines d'hallucination :

• Ne pas savoir : Le LLM manque de contexte spécifique au projet (par exemple, constructeurs valides, méthodes d'usine ou modèles d'utilisation) pour générer du code correct.
• Ne pas suivre : Même lorsque des contraintes sont fournies, le LLM échoue à s'y conformer (par exemple, en violant la validité des symboles ou les protocoles d'appels d'API), souvent en raison d'un manque de mécanismes d'application.

Méthodologie : MocklessTester

Les auteurs proposent MocklessTester, une approche de génération de tests unitaires sans simulation pour Java qui emploie un flux de travail itératif planifier–générer–valider–corriger. Le système est construit autour de deux stratégies principales pour répondre aux causes racines identifiées : Génération enrichie par le contexte et Correction imposée par les contraintes.

1. Phase de Préparation

Avant le début de la génération de tests, MocklessTester analyse le dépôt cible pour construire trois artefacts spécifiques au projet :

• Graphe de Propriétés de Code (CPG) : Construit à l'aide de Joern, ce graphe capture l'utilisation des dépendances, permettant la récupération d'exemples réels de construction d'objets et d'appels d'API via le découpage de programme.
• ClassIndex : Un registre de toutes les classes, méthodes, constructeurs et imports visibles par le projet. Il sert de vérité terrain pour valider les symboles et résoudre les types lors de la réparation.
• Modèle de Typestate de Markov : Un modèle probabiliste capturant les ordres d'appels de méthodes valides pour les API d'état. Il est initialisé à partir de preuves issues du code source et mis à jour dynamiquement en fonction des résultats des tests pour détecter les séquences d'appels illégales.

2. Boucle Itérative Multi-Agents

Le processus de génération implique cinq agents : Initialisateur, Planificateur, Générateur, Validateur et Correcteur.

• Génération enrichie par le contexte : Pour atténuer le problème de « Ne pas savoir », le Générateur ne repose pas uniquement sur le code source de la classe à tester (CUT). À la place, un découpeur de programme extrait des modèles réels d'instanciation et d'utilisation des dépendances à partir du code de production et de test du projet. Ces modèles sont injectés dans l'invite pour guider le LLM dans la création d'instanciations d'objets plausibles.
• Correction imposée par les contraintes : Pour atténuer le problème de « Ne pas suivre », le Correcteur emploie un mécanisme de réparation en deux étapes pour les tests échouant :
  • Étape I (Correcteur I) : Génère une correction initiale basée sur les retours d'exécution (erreurs de compilation/temps d'exécution).
  • Étape II (Correcteur II) : Si la correction initiale viole les contraintes, une seconde réparation est déclenchée. Le LLM doit générer une correction satisfaisant trois niveaux de contraintes et fournir une justification structurée expliquant comment la correction résout l'échec et adhère aux règles :
    • Niveau Symbole : Garantit que toutes les classes, méthodes et imports existent dans le ClassIndex.
    • Niveau Protocole : Garantit que les séquences d'appels d'API respectent le modèle de typestate de Markov (par exemple, initialiser l'état avant l'utilisation).
    • Niveau Itération : Exploite la Mémoire d'Expérience, qui stocke des modèles de réparation réussis (« tests or »), des recettes de correction et des anti-modèles pour éviter de répéter les échecs connus.

Contributions Clés

1. Prompting enrichi par le contexte : Les auteurs identifient les modèles d'utilisation des dépendances comme un contexte critique. Ils proposent une stratégie qui enrichit le LLM avec des exemples réels d'instanciation de dépendances extraits du projet cible, réduisant considérablement les hallucinations causées par une connaissance insuffisante.
2. Mécanisme de correction imposée par les contraintes : Un processus de réparation en deux étapes novateur qui impose des contraintes au niveau des symboles, du protocole et de l'itération. Crucialement, la seconde étape exige que le modèle génère une justification structurée pour ses corrections, ciblant directement les hallucinations de type « ne pas suivre ».
3. Première approche LLM sans simulation pour Java : MocklessTester est présenté comme la première approche basée sur les LLM pour Java ciblant explicitement les dépendances externes, faisant progresser les tests automatisés des tests unitaires simulés vers une exécution réaliste.
4. Évaluation empirique complète : L'étude introduit la Couverture de Ligne de Dépendance (DepLC) comme nouvelle métrique pour mesurer l'étendue du code réel du projet exercé au-delà de la Classe Sous Test (CUT).

Résultats Expérimentaux

L'approche a été évaluée sur Defects4J (14 projets, 130 classes) et un nouveau benchmark, Deps4J (5 projets récents multi-modules, 30 classes), par rapport à la référence de l'état de l'art PANTA.

• Efficacité :

  • Sur Defects4J, MocklessTester a amélioré la couverture de ligne moyenne de 19,99 % (68,83 % → 88,82 %) et la couverture de branche de 24,90 % (58,84 % → 83,74 %). Le score de mutation a augmenté de 13,67 %.
  • Sur Deps4J, il a amélioré la couverture de ligne de 22,69 % et la couverture de branche de 15,78 %, tout en maintenant des scores de mutation comparables.
  • Couverture des Dépendances : MocklessTester a couvert significativement plus de code réel de dépendance, augmentant la DepLC du projet de 378 lignes sur Defects4J et de 55 lignes sur Deps4J par rapport à la référence.
  • Efficacité des Tests : Malgré la génération de moins de tests par projet en moyenne, MocklessTester a atteint une couverture plus élevée, indiquant une qualité supérieure par test.

• Efficience :

  • MocklessTester a entraîné des coûts totaux en jetons et en temps plus élevés en raison de l'exécution de plus d'itérations pour atteindre une couverture plus élevée.
  • Cependant, le coût reste pratique : une moyenne de 108,97 secondes et 26,59k jetons par méthode sur Defects4J.
  • Notamment, MocklessTester a été substantiellement plus rapide par itération (environ 58 % de temps en moins) que la référence, suggérant que ses itérations sont plus efficaces en termes de temps même si elles sont plus nombreuses.

• Étude d'Ablation :

  • La suppression de la Récupération d'Usage a causé la plus grande baisse de performance, confirmant l'importance du contexte.
  • La suppression des contraintes de niveau Protocole a eu le deuxième impact le plus important, soulignant la difficulté de gérer des objets d'état sans application explicite.
  • Les contraintes de niveau Symbole et de niveau Itération ont également fourni des améliorations significatives, bien que légèrement plus faibles.

Importance et Revendications

L'article revendique que MocklessTester répond avec succès aux limitations des tests basés sur la simulation en permettant la génération de tests qui exercent de véritables dépendances de projet. En traitant systématiquement le « ne pas savoir » par l'enrichissement du contexte et le « ne pas suivre » par l'imposition de contraintes, l'approche atteint des résultats de l'état de l'art en matière de couverture de ligne, de couverture de branche et de score de mutation sur des benchmarks établis et nouveaux.

Les auteurs soulignent que si l'approche nécessite des ressources de calcul plus importantes que les méthodes de référence, le compromis produit des tests non seulement plus complets en couverture, mais aussi plus robustes face à l'évolution des dépendances. L'introduction de DepLC offre une nouvelle dimension pour l'évaluation des suites de tests, allant au-delà de la CUT pour mesurer l'exécution réelle du système plus large. Le travail suggère que les améliorations futures pourraient impliquer des mécanismes de mémoire plus riches et une génération d'entrée consciente de la grammaire pour les composants centrés sur l'analyseur.