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

Software is nooit echt af. Zelfs nadat een programma is uitgebracht, moeten ontwikkelaars er voortdurend naar terugkeren om fouten te herstellen, nieuwe functies toe te voegen en zich aan te passen aan veranderende behoeften. Dit voortdurende werk wordt onderhoud genoemd, en het vereist vaak meer inspanning dan de initiële creatie van de software zelf. Om dit werk beheersbaar te houden, laten programmeurs soms aantekeningen achter in hun code, waarin ze toegeven dat een bepaald deel slordig, tijdelijk of niet helemaal juist is. Ze kunnen een opmerking schrijven als: "Dit is een hack," of "Los dit later op." In de wereld van software engineering worden deze eerlijke bekentenissen bekend als zelf-toegegeven technische schuld. Het is alsof een ontwikkelaar zegt: "Ik weet dat dit niet de beste manier is om het te doen, maar we moesten het nu even afkrijgen." Hoewel onderzoekers al lang deze aantekeningen bestuderen in de hoofdcode die een programma uitvoert, hebben ze de aantekeningen in de code die wordt gebruikt om dat programma te testen grotendeels genegeerd. Dit is een aanzienlijke nalatigheid, want als de tests zelf gebrekkig of slecht geschreven zijn, wordt het hele softwaresysteem onbetrouwbaar.

Een team onderzoekers aan de Universiteit van Manitoba zette zich in om deze verborgen laag van schuld te begrijpen. Ze richtten zich op een specifiek type software geschreven in Java, een taal die veel wordt gebruikt voor het bouwen van complexe applicaties. Om een duidelijk beeld te krijgen, verzamelden ze een enorme collectie van meer dan één miljoen reacties uit duizend verschillende open-source projecten. Uit deze enorme poel selecteerden ze willekeurig vijftig duizend reacties om handmatig te onderzoeken. Deze handmatige controle was zwaar werk, waarbij de onderzoekers elke notitie moesten lezen en beslissen of het een oprechte bekentenis van een probleem was of slechts een standaard uitleg. Na het filteren van reacties die niet relevant waren of afkomstig waren van een enkel project dat de data zou scheef trekken, identificeerden ze 615 reacties die echte voorbeelden waren van technische schuld in testcode.

De onderzoekers ontdekten dat de aard van deze schulden in testcode heel anders is dan wat er in de hoofdapplicatiecode wordt gevonden. Ze sorteerden de 615 instanties in elf verschillende categorieën. Sommige hiervan waren bekend, zoals aantekeningen over slecht ontwerp of ontbrekende documentatie. Echter, vier categorieën waren geheel nieuw en specifiek voor de wereld van testen. Deze omvatten "beperkte tests", waarbij een ontwikkelaar toegeeft dat de test slechts een klein, niet-representatief deel van het probleem controleert; "overslaan-tests", waarbij een test expliciet wordt uitgeschakeld omdat deze niet kan draaien in de huidige omgeving; "on hold", waarbij een test wacht tot een externe tool of service beschikbaar is; en "onzekerheid", waarbij de ontwikkelaar niet zeker weet of de test zelfs wel correct is. Deze taxonomie onthulde dat testcode zijn eigen unieke lasten draagt, die vaak gerelateerd zijn aan de specifieke uitdagingen van het valideren van softwaregedrag in plaats van het bouwen ervan.

Nadat ze in kaart hadden gebracht hoe deze schulden eruitzien, stelde het team een tweede, meer praktische vraag: Kunnen computers ze automatisch vinden? Ze testten zeven bestaande tools die ontworpen zijn om deze aantekeningen in reguliere broncode op te sporen. Ze testten ook een reeks kunstmatige intelligentiemodellen, inclusief zowel open-source modellen als krachtige, propriëtaire systemen van grote technologiebedrijven. De resultaten waren verrassend. De bestaande tools, die vertrouwen op het zoeken naar specifieke trefwoorden zoals "TODO" of "FIXME", presteerden het best onder de traditionele methoden, maar ze misten nog steeds meer dan een derde van de werkelijke schulden. Ze waren goed in het correct identificeren wanneer ze iets vonden, maar ze faalden in het vinden van veel van de echte problemen.

De kunstmatige intelligentiemodellen presteerden op andere manieren zelfs nog slechter. De open-source modellen hadden moeite om de schulden überhaupt te vinden, en herkenden ze vaak pas als de aantekeningen zeer duidelijke trefwoorden bevatten. Wanneer ze wel iets vonden, waren ze vaak onjuist. De propriëtaire modellen, die over het algemeen als geavanceerder worden beschouwd, vertoonden het tegenovergestelde probleem. Ze vonden bijna elke schuld, maar ze markeerden ook honderden onschuldige reacties als problemen. Ze waren zo gretig om problemen te vinden dat ze routinematige verklaringen aanzagen voor bekentenissen van falen. Uiteindelijk kon noch de traditionele tools, noch de meest geavanceerde AI-systemen deze schulden in testcode betrouwbaar detecteren.

De studie concludeert dat de manier waarop ontwikkelaars over problemen schrijven in testcode fundamenteel verschilt van hoe ze over problemen schrijven in de hoofdcode. De aantekeningen in testbestanden gebruiken vaak taal die specifiek is voor het testproces, zoals het vermelden dat een test "uitgeschakeld" of "overgeslagen" is, wat standaard tools en AI-modellen niet herkennen als een teken van schuld. De onderzoekers kwamen tot de conclusie dat de huidige methoden nog niet klaar zijn om deze complexiteit aan te kunnen. Ze hebben een nieuwe dataset en een gedetailleerde kaart van deze soorten schuld gecreëerd om toekomstige onderzoekers te helpen bij het bouwen van betere detectietools. Tot die tijd blijft de taak om deze verborgen gebreken in testcode te vinden en te herstellen een klus die menselijke aandacht vereist.