A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

Le logiciel n'est jamais vraiment terminé. Même après la sortie d'un programme, les développeurs doivent constamment y revenir pour corriger des erreurs, ajouter de nouvelles fonctionnalités et s'adapter aux besoins changeants. Ce travail continu est appelé maintenance, et il nécessite souvent plus d'efforts que la création initiale du logiciel lui-même. Pour rendre ce travail gérable, les programmeurs laissent parfois des notes dans leur code, admettant qu'une section particulière est désordonnée, temporaire ou pas tout à fait correcte. Ils peuvent écrire un commentaire tel que : « C'est un bidouillage » ou « À corriger plus tard ». Dans le monde du génie logiciel, ces aveux honnêtes sont connus sous le nom de dette technique auto-avouée. C'est comme si un développeur disait : « Je sais que ce n'est pas la meilleure façon de faire, mais il fallait que ce soit fait maintenant. » Bien que les chercheurs étudient depuis longtemps ces notes dans le code principal qui exécute un programme, ils ont largement ignoré les notes trouvées dans le code utilisé pour tester ce programme. C'est un oubli important, car si les tests eux-mêmes sont défectueux ou mal écrits, l'ensemble du système logiciel devient peu fiable.

Une équipe de chercheurs de l'Université du Manitoba s'est donné pour mission de comprendre cette couche de dette cachée. Ils se sont concentrés sur un type spécifique de logiciel écrit en Java, un langage largement utilisé pour construire des applications complexes. Pour obtenir une image claire, ils ont rassemblé une collection massive de plus d'un million de commentaires provenant de mille projets open-source différents. De ce vaste réservoir, ils ont sélectionné au hasard cinquante mille commentaires pour un examen manuel. Ce travail de revue manuelle était laborieux, exigeant que les chercheurs lisent chaque note et décident s'il s'agissait d'un véritable aveu de problème ou simplement d'une explication standard. Après avoir filtré les commentaires qui n'étaient pas pertinents ou qui provenaient d'un seul projet biaisant les données, ils ont identifié 615 commentaires qui étaient de véritables exemples de dette technique dans le code de test.

Les chercheurs ont découvert que la nature de ces dettes dans le code de test est très différente de celle que l'on trouve dans le code de l'application principale. Ils ont classé les 615 occurrences en onze catégories distinctes. Certaines étaient familières, comme des notes concernant une mauvaise conception ou une documentation manquante. Cependant, quatre catégories étaient entièrement nouvelles et spécifiques au monde des tests. Celles-ci comprenaient les « tests limités », où un développeur admet que le test ne vérifie qu'une infime partie non représentative du problème ; les « tests sautés », où un test est explicitement désactivé parce qu'il ne peut pas s'exécuter dans l'environnement actuel ; « en attente », où un test attend qu'un outil ou un service externe soit disponible ; et « incertitude », où le développeur n'est pas certain que le test soit même correct. Cette taxonomie a révélé que le code de test porte ses propres fardeaux uniques, souvent liés aux défis spécifiques de la validation du comportement d'un logiciel plutôt qu'à sa construction.

Ayant cartographié ce à quoi ressemblent ces dettes, l'équipe a posé une seconde question, plus pratique : les ordinateurs peuvent-ils les trouver automatiquement ? Ils ont testé sept outils existants conçus pour repérer ces notes dans le code source régulier. Ils ont également testé une gamme de modèles d'intelligence artificielle, incluant à la fois des modèles open-source et des systèmes propriétaires puissants provenant de grandes entreprises technologiques. Les résultats ont été surprenants. Les outils existants, qui reposent sur la recherche de mots-clés spécifiques comme « TODO » ou « FIXME », ont obtenu les meilleures performances parmi les méthodes traditionnelles, mais ils passaient encore à côté d'un tiers des dettes réelles. Ils étaient bons pour être corrects lorsqu'ils trouvaient quelque chose, mais ils échouaient à trouver de nombreux problèmes réels.

Les modèles d'intelligence artificielle ont été encore moins performants, mais de manières différentes. Les modèles open-source ont eu du mal à trouver les dettes, échouant souvent à les reconnaître à moins que les notes ne contiennent des mots-clés très évidents. Lorsqu'ils trouvaient quelque chose, ils se trompaient fréquemment. Les modèles propriétaires, qui sont généralement considérés comme plus avancés, présentaient le problème opposé. Ils trouvaient presque toutes les dettes, mais ils signalaient aussi des centaines de commentaires inoffensifs comme étant des problèmes. Ils étaient si impatients de trouver des problèmes qu'ils confondaient des explications de routine avec des aveux d'échec. En fin de compte, ni les outils traditionnels ni les systèmes d'IA les plus avancés ne pouvaient détecter ces dettes dans le code de test de manière fiable.

L'étude conclut que la façon dont les développeurs écrivent sur les problèmes dans le code de test est fondamentalement différente de la façon dont ils écrivent sur les problèmes dans le code principal. Les notes dans les fichiers de test utilisent souvent un langage spécifique au processus de test, comme mentionner qu'un test est « désactivé » ou « sauté », ce que les outils standards et les modèles d'IA ne reconnaissent pas comme un signe de dette. Les chercheurs ont constaté que les méthodes actuelles ne sont pas encore prêtes à gérer cette complexité. Ils ont créé un nouvel ensemble de données et une carte détaillée de ces types de dettes pour aider les futurs chercheurs à construire de meilleurs outils de détection. D'ici là, la tâche consistant à trouver et à corriger ces failles cachées dans le code de test reste un travail qui nécessite l'attention humaine.