Understanding Self-Admitted Technical Debt in Test Code: An Empirical Study
Cette étude empirique examine la distribution, les types et la relation avec la qualité des tests de la dette technique auto-déclarée (SATD) dans le code de test à travers 50 dépôts, révélant que, bien que la SATD soit prévalente et distincte de la SATD du code de production, elle n'est pas directement associée aux odeurs de code (test smells), et démontrant qu'un modèle basé sur CodeBERT classifie efficacement ces types de dettes pour une meilleure gestion.
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 le développement de logiciels comme la construction d'une maison massive et complexe. Parfois, pour respecter une échéance ou sortir rapidement un prototype, les constructeurs (les développeurs) prennent des raccourcis. Ils pourraient utiliser une porte temporaire au lieu d'une porte solide, ou laisser une pièce inachevée avec un post-it sur le mur disant : « À réparer plus tard ». Dans le monde du code, ces raccourcis sont appelés Dette Technique, et les post-its sont appelés Dette Technique Auto-Admise (SATD).
Pendant des années, des chercheurs ont étudié ces post-its, mais ils se sont principalement concentrés sur les notes collées sur les murs du salon (le code de production principal). Ils ont largement ignoré les notes collées sur les plans et les listes de contrôle d'inspection (le code de test). Ce document décide de enfin nettoyer la boîte à outils et de regarder spécifiquement les notes trouvées dans le code de test.
Voici ce que les chercheurs ont découvert, expliqué simplement :
1. Les post-its sont partout (même dans la salle de test)
Les chercheurs ont examiné 50 projets logiciels différents (comme un quartier de 50 maisons différentes). Ils ont découvert que, bien qu'il y ait moins de post-its dans le code de test que dans le code principal, il y en a tout de même beaucoup — environ 15,6 % de tous les post-its qu'ils ont trouvés étaient dans le code de test.
L'analogie : Si le code principal est la structure de la maison, le code de test est la liste de contrôle de l'inspecteur. L'étude a montré que les inspecteurs sont tout aussi susceptibles de griffonner « À vérifier plus tard » sur leurs listes que les constructeurs ne le font sur les murs. Ce n'est pas une quantité minuscule ou négligeable ; c'est une part significative du travail.
2. Les notes ne correspondent pas aux « odeurs »
Dans le logiciel, il existe des outils automatisés qui détectent les « mauvaises odeurs » dans le code de test — comme un test trop long, confus ou instable (qui passe parfois, échoue parfois). On appelle cela des Test Smells (odeurs de test).
Les chercheurs voulaient voir si les post-its (SATD) se trouvaient généralement juste à côté de ces mauvaises odeurs.
- Le résultat : Étonnamment, non. Les post-its et les mauvaises odeurs apparaissent généralement à des endroits différents.
- L'analogie : Imaginez un inspecteur de maison. Les « mauvaises odeurs » sont comme une odeur de moisissure dans le sous-sol (un problème structurel détecté par la machine). Les « post-its » sont comme une note manuscrite disant : « Je n'ai pas fini de peindre ce mur ». L'étude a montré que les endroits avec l'odeur de moisissure n'étaient pas nécessairement les mêmes que ceux avec les notes de peinture inachevée. Les développeurs signalent des problèmes que les outils de « détection d'odeur » automatisés ne voient pas.
3. Que disent réellement les notes ?
L'équipe a lu à la main 506 de ces post-its de code de test pour comprendre ce dont les développeurs se plaignaient réellement. Ils les ont classés dans un nouveau « dictionnaire » de 20 types de problèmes différents, regroupés en 5 catégories principales :
- Problèmes liés à la production : Notes disant : « Ce test échouera si vous l'exécutez sur Windows », ou « Je ne peux pas finir ce test parce que le code principal a un bug ».
- Tests incomplets : La note la plus courante : « J'ai commencé ce test, mais je n'ai pas fini d'écrire la partie qui vérifie si le résultat est correct ».
- Mauvaise conception / Solutions de contournement : Notes comme : « J'ai dû utiliser une astuce bancale pour faire fonctionner ce test car le code est trop verrouillé », ou « Ce test est écrit de manière maladroite ».
- Maintenance : Notes disant : « Ce test est instable », « Nous devons mettre à jour cela pour la nouvelle version du logiciel », ou « Ce test est inutile, supprimez-le ».
- Doutes : Notes demandant : « À quoi sert même ce test ? » ou « Ai-je vraiment besoin de ce minuteur de sommeil ? »
Le point essentiel : La plupart de ces notes concernent un travail incomplet. Les développeurs écrivent souvent un test, mais s'arrêtent avant d'ajouter la vérification finale, laissant une note pour finir plus tard.
4. Un robot peut-il lire ces notes ?
Les chercheurs ont essayé d'apprendre aux ordinateurs à lire ces post-its et à les classer automatiquement dans les bonnes catégories. Ils ont testé plusieurs « cerveaux » (algorithmes), y compris des modèles très avancés basés sur l'IA.
- Le gagnant : Un modèle d'IA spécialisé appelé CodeBERT a été le meilleur pour la tâche. Il identifiait correctement le type de dette environ 70 % du temps.
- La surprise : Une IA plus récente et plus puissante (GPT-4) était en fait meilleure pour trouver les notes rares et étranges que les autres manquaient, même si elle n'était pas la plus constante globalement.
- Le problème : L'IA a le plus de mal avec la catégorie « Échecs » (notes concernant l'échec des tests). C'était en partie parce qu'il y avait très peu d'exemples de ces notes dans leurs données, ce qui rendait difficile l'apprentissage du modèle par le robot.
Résumé
Ce document nous indique que le code de test possède son propre ensemble unique de « tâches inachevées » qui est différent du code principal. Les développeurs écrivent des notes sur des tests incomplets, des conceptions médiocres et des résultats instables que les outils automatisés ne détectent pas. Bien que nous puissions désormais utiliser l'IA pour aider à trier ces notes, la technologie a encore besoin de pratique, surtout sur les cas rares et complexes.
La leçon principale est : N'ignorez pas les notes sur les listes de contrôle de test. Elles révèlent un désordre différent dans le logiciel qui nécessite un type de nettoyage différent.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.