Understanding Self-Admitted Technical Debt in Test Code: An Empirical Study
Diese empirische Studie untersucht die Verteilung, die Arten und die Beziehung zur Testqualität von selbst zugegebenen technischen Schulden (Self-Admitted Technical Debt, SATD) im Testcode über 50 Repositories, wobei sie aufzeigt, dass SATD zwar weit verbreitet und von SATD in Produktionscode verschieden ist, jedoch nicht direkt mit Test-Smells zusammenhängt, und demonstriert, dass ein auf CodeBERT basierendes Modell diese Schuldenarten effektiv klassifiziert, um ein besseres Management zu ermöglichen.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich die Softwareentwicklung wie den Bau eines massiven, komplexen Hauses vor. Manchmal nehmen die Baumeister (Entwickler), um eine Frist einzuhalten oder schnell einen Prototyp fertigzustellen, Abkürzungen. Sie verwenden vielleicht eine provisorische Tür anstelle einer soliden oder lassen einen Raum unfertig mit einem Klebezettel an der Wand, auf dem steht: „Später reparieren“. In der Welt des Codings werden diese Abkürzungen als Technical Debt (technische Schulden) bezeichnet, und die Klebezettel werden als Self-Admitted Technical Debt (SATD) bezeichnet.
Seit Jahren untersuchen Forscher diese Klebezettel, aber sie haben hauptsächlich nach den Zetteln gesucht, die an den Wänden des Wohnzimmers (dem Produktionscode) kleben. Sie haben die Notizen, die auf den Bauplänen und Inspektionschecklisten (dem Testcode) kleben, weitgehend ignoriert. Diese Arbeit beschließt, endlich den Werkzeugkasten aufzuräumen und sich gezielt die Notizen im Testcode anzusehen.
Hier ist, was die Forscher herausgefunden haben, einfach erklärt:
1. Die Klebezettel sind überall (sogar im Testraum)
Die Forscher untersuchten 50 verschiedene Softwareprojekte (wie eine Nachbarschaft aus 50 verschiedenen Häusern). Sie fanden heraus, dass es im Testcode zwar weniger Klebezettel gibt als im Hauptcode, aber es gibt immer noch viele von ihnen – etwa 15,6 % aller gefundenen Notizen befanden sich im Testcode.
Die Analogie: Wenn der Hauptcode die Struktur eines Hauses ist, dann ist der Testcode die Checkliste des Inspektors. Die Studie ergab, dass Inspektoren genauso wahrscheinlich „Später prüfen“ auf ihre Checklisten kritzeln wie die Baumeister an die Wände. Es ist keine winzige, vernachlässigbare Menge; es ist ein bedeutender Teil der Arbeit.
2. Die Notizen passen nicht zu den „Gerüchen“
In der Software gibt es automatisierte Werkzeuge, die „schlechte Gerüche“ im Testcode aufspüren – wie etwa einen Test, der zu lang, verwirrend oder „flaky“ (instabil, mal besteht er, mal schlägt er fehl) ist. Diese werden als Test Smells bezeichnet.
Die Forscher wollten wissen, ob die Klebezettel (SATD) normalerweise direkt neben diesen schlechten Gerüchen zu finden sind.
- Das Ergebnis: Überraschenderweise: Nein. Die Klebezettel und die schlechten Gerüche treten meist an unterschiedlichen Stellen auf.
- Die Analogie: Stellen Sie sich einen Hausinspektor vor. Die „schlechten Gerüche“ sind wie ein modriger Geruch im Keller (ein strukturelles Problem, das die Maschine erkennt). Die „Klebezettel“ sind wie eine handschriftliche Notiz: „Ich habe diese Wand noch nicht fertig gestrichen.“ Die Studie fand heraus, dass die Orte mit dem modrigen Geruch nicht zwangsläufig dieselben Orte waren wie die mit den unfertigen Malerarbeiten. Entwickler markieren Probleme, die die automatisierten „Schnüffeler“-Werkzeuge übersehen.
3. Was sagen die Notizen eigentlich aus?
Das Team hat 506 dieser Testcode-Klebezettel von Hand gelesen, um herauszufinden, worüber sich die Entwickler tatsächlich beschweren. Sie haben sie in ein neues „Wörterbuch“ aus 20 verschiedenen Arten von Problemen sortiert, die in 5 Hauptkategorien gruppiert sind:
- Produktionsbezogene Probleme: Notizen wie: „Dieser Test wird fehlschlagen, wenn man ihn unter Windows ausführt“, oder „Ich kann diesen Test nicht abschließen, weil der Hauptcode einen Bug hat.“
- Unvollständige Tests: Die häufigste Notiz: „Ich habe diesen Test begonnen, aber den Teil, der prüft, ob das Ergebnis korrekt ist, noch nicht fertig geschrieben.“
- Schlechtes Design/Workarounds: Notizen wie: „Ich musste einen Hack benutzen, um diesen Test zum Laufen zu bringen, weil der Code zu starr ist“, oder „Dieser Test ist umständlich geschrieben.“
- Wartung: Notizen wie: „Dieser Test ist flaky“, „Wir müssen dies für die neue Softwareversion aktualisieren“ oder „Dieser Test ist nutzlos, lösche ihn.“
- Zweifel: Notizen wie: „Wozu dient dieser Test überhaupt?“ oder „Brauche ich diesen Sleep-Timer wirklich?“
Das große Fazit: Die meisten dieser Notizen betreffen unvollständige Arbeit. Entwickler schreiben oft einen Test, hören aber auf, bevor sie die endgültige Prüfung hinzufügen, und hinterlassen eine Notiz, um es später zu Ende zu führen.
4. Kann ein Roboter diese Notizen lesen?
Die Forscher versuchten, Computern beizubringen, diese Klebezettel zu lesen und sie automatisch in die richtigen Kategorien zu sortieren. Sie probierten verschiedene „Gehirne“ (Algorithmen) aus, darunter auch sehr fortschrittliche KI-basierte Modelle.
- Der Gewinner: Ein spezialisiertes KI-Modell namens CodeBERT war am besten darin. Es identifizierte die Art der technischen Schuld etwa 70 % der Zeit korrekt.
- Die Überraschung: Eine neuere, leistungsstärkere KI (GPT-4) war tatsächlich besser darin, die seltenen und merkwürdigen Notizen zu finden, die die anderen übersehen hatten, auch wenn sie insgesamt nicht so konsistent war.
- Das Problem: Die KI hatte am meisten Schwierigkeiten mit der Kategorie „Failures“ (Notizen über fehlschlagende Tests). Dies lag teilweise daran, dass es in ihren Daten nur sehr wenige Beispiele für diese Art von Notizen gab, was es dem Roboter schwer machte, das Muster zu lernen.
Zusammenfassung
Diese Arbeit zeigt uns, dass Testcode seine eigenen, einzigartigen „unerledigten Angelegenheiten“ hat, die sich vom Hauptcode unterscheiden. Entwickler schreiben Notizen über unvollständige Tests, schlechtes Design und instabile Ergebnisse, die automatisierte Tools nicht erfassen. Während wir nun KI nutzen können, um diese Notizen zu sortieren, muss die Technologie noch mehr üben, insbesondere bei den seltenen und schwierigen Fällen.
Die wichtigste Lektion lautet: Ignorieren Sie nicht die Notizen auf den Test-Checklisten. Sie offenbaren ein anderes Maß an Unordnung in der Software, das eine andere Art der Bereinigung erfordert.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.