Understanding Self-Admitted Technical Debt in Test Code: An Empirical Study
Deze empirische studie onderzoekt de distributie, typen en de relatie met de kwaliteit van testcode van Self-Admitted Technical Debt (SATD) in 50 repositories, waarbij wordt onthuld dat hoewel SATD wijdverbreid is en verschilt van productiecode-SATD, het niet direct geassocieerd is met test-smells, en demonstrerend dat een op CodeBERT gebaseerd model deze typen schulden effectief classificeert voor beter beheer.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je softwareontwikkeling voor als het bouwen van een enorm, complex huis. Soms, om een deadline te halen of snel een prototype op de benen te krijgen, nemen de bouwers (ontwikkelaars) kortere wegen. Ze gebruiken dan misschien een tijdelijke deur in plaats van een stevige deur, of laten een kamer onafgewerkt achter met een briefje op de muur waarop staat: "Later repareren." In de wereld van programmeren worden deze kortere wegen Technische Schuld genoemd, en de briefjes op de muur zijn Self-Admitted Technical Debt (SATD).
Jarenlang hebben onderzoekers deze briefjes bestudeerd, maar ze hebben vooral gekeken naar de briefjes die op de muren van de woonkamer zitten (de hoofdproductiecode). Ze negeerden grotendeels de briefjes die op de blauwdrukken en inspectielijsten zitten (de testcode). Dit artikel besluit eindelijk de gereedschapskist leeg te maken en kijkt specifiek naar de briefjes die in de testcode worden gevonden.
Hier is wat de onderzoekers hebben gevonden, eenvoudig uitgelegd:
1. De briefjes zijn overal (zelfs in de testruimte)
De onderzoekers keken naar 50 verschillende softwareprojecten (zoals een buurt met 50 verschillende huizen). Ze ontdekten dat er weliswaar minder briefjes in de testcode staan dan in de hoofdcode, maar er zijn er nog steeds genoeg—ongeveer 15,6% van alle briefjes die ze vonden, bevond zich in de testcode.
De analogie: Als de hoofdcode de structuur van het huis is, dan is de testcode de checklist van de inspecteur. De studie toonde aan dat inspecteurs net zo vaak "Later controleren" op hun checklists krabbelen als de bouwers op de muren. Het is geen kleine, verwaarloosbare hoeveelheid; het is een aanzienlijk deel van het werk.
2. De briefjes komen niet overeen met de "geuren"
In software zijn er geautomatiseerde tools die "slechte geuren" opsporen in testcode—zoals een test die te lang is, verwarrend of onbetrouwbaar (soms slaagt hij, soms faalt hij). Dit worden Test Smells genoemd.
De onderzoekers wilden zien of de briefjes (SATD) meestal direct naast deze slechte geuren werden gevonden.
- De bevinding: Verrassend genoeg niet. De briefjes en de slechte geuren verschijnen meestal op verschillende plaatsen.
- De analogie: Stel je een huisinspecteur voor. De "slechte geuren" zijn als een muffe geur in de kelder (een structureel probleem dat de machine detecteert). De "briefjes" zijn als een handgeschreven notitie: "Ik heb deze muur niet afgeschilderd." De studie vond dat de plekken met de muffe geur niet noodzakelijkerwijs dezelfde plekken waren met de briefjes over de onafgewerkte schilderbeurt. Ontwikkelaars signaleren problemen die de geautomatiseerde "snuffeltools" missen.
3. Waar gaan de briefjes eigenlijk over?
Het team heeft 506 van deze briefjes in de testcode handmatig gelezen om te achterhalen waar ontwikkelaars zich precies over beklagen. Ze hebben ze gesorteerd in een nieuwe "woordenlijst" van 20 verschillende soorten problemen, gegroepeerd in 5 hoofdcategorieën:
- Productie-gerelateerde problemen: Notities zoals: "Deze test zal falen als je hem op Windows draait," of "Ik kan deze test niet afmaken omdat de hoofdcode een bug heeft."
- Onvolledige tests: De meest voorkomende notitie: "Ik ben begonnen met deze test, maar ik ben gestopt voordat ik het deel heb geschreven dat controleert of het resultaat correct is."
- Slecht ontwerp/Workarounds: Notities zoals: "Ik moest een hacky truc gebruiken om deze test te laten werken omdat de code te strikt is," of "Deze test is op een onhandige manier geschreven."
- Onderhoud: Notities zoals: "Deze test is onbetrouwbaar (flaky)," "We moeten dit updaten voor de nieuwe softwareversie," of "Deze test is nutteloos, verwijder hem."
- Twijfel: Notities die vragen: "Waar dient deze test eigenlijk voor?" of "Heb ik deze sleep-timer echt nodig?"
De belangrijkste conclusie: De meeste van deze notities gaan over onvoltooid werk. Ontwikkelaars schrijven vaak een test, maar stoppen voordat ze de laatste controle toevoegen, en laten een briefje achter om het later af te maken.
4. Kan een robot deze briefjes lezen?
De onderzoekers probeerden computers te leren deze briefjes te lezen en ze automatisch in de juiste categorieën in te delen. Ze probeerden verschillende "hersenen" (algoritmen), inclusief enkele zeer geavanceerde modellen gebaseerd op AI.
- De winnaar: Een gespecialiseerd AI-model genaamd CodeBERT was het beste in deze taak. Het identificeerde het type technische schuld ongeveer 70% van de tijd correct.
- De verrassing: Een nieuwere, krachtigere AI (GPT-4) was eigenlijk beter in het vinden van de zeldzame en vreemde notities die de anderen misten, ook al was het model minder consistent over het algemeen.
- Het probleem: De AI had de meeste moeite met de categorie "Fouten" (notities over falende tests). Dit kwam deels doordat er zeer weinig voorbeelden van deze notities in hun data zaten, waardoor het voor de robot moeilijk was om het patroon te leren.
Samenvatting
Dit artikel vertelt ons dat testcode zijn eigen unieke set van "onvoltooide zaken" heeft die anders is dan de hoofdcode. Ontwikkelaars schrijven notities over onvoltooide tests, slecht ontwerp en onbetrouwbare resultaten die automatische tools niet oppikken. Hoewel we nu AI kunnen gebruiken om te helpen deze notities te sorteren, moet de technologie nog meer oefenen, vooral bij de zeldzame en lastige gevallen.
De belangrijkste les is: Negeer de briefjes op de test-checklists niet. Ze onthullen een ander soort rommel in de software die een ander soort opruiming vereist.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.