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

Software ist niemals wirklich fertig. Selbst nachdem ein Programm veröffentlicht wurde, müssen Entwickler ständig darauf zurückkommen, um Fehler zu beheben, neue Funktionen hinzuzufügen und sich an veränderte Bedürfnisse anzupassen. Diese fortlaufende Arbeit wird als Wartung bezeichnet und erfordert oft mehr Aufwand als die ursprüngliche Erstellung der Software selbst. Um diese Arbeit bewältigbar zu halten, hinterlassen Programmierer manchmal Notizen in ihrem Code, in denen sie zugeben, dass ein bestimmter Abschnitt unordentlich, temporär oder nicht ganz richtig ist. Sie schreiben vielleicht einen Kommentar wie: „Das ist ein Hack“ oder „Später korrigieren“. In der Welt des Software-Engineerings werden diese ehrlichen Geständnisse als selbstzugegebene technische Schulden bekannt. Sie sind wie ein Entwickler, der sagt: „Ich weiß, dass dies nicht der beste Weg ist, aber wir mussten es jetzt erledigen.“ Während Forscher diese Notizen im Hauptcode, der ein Programm ausführt, schon lange untersuchen, haben sie die Notizen, die im Code zur Testung dieses Programms gefunden werden, weitgehend ignoriert. Dies ist ein erhebliches Versäumnis, denn wenn die Tests selbst fehlerhaft oder schlecht geschrieben sind, wird das gesamte Softwaresystem unzuverlässig.

Ein Forschungsteam der University of Manitoba machte sich daran, diese verborgene Ebene der Schulden zu verstehen. Sie konzentrierten sich auf eine spezifische Art von Software, die in Java geschrieben wurde, einer Sprache, die weit verbreitet ist, um komplexe Anwendungen zu bauen. Um ein klares Bild zu erhalten, sammelten sie eine massive Sammlung von über einer Million Kommentaren aus tausend verschiedenen Open-Source-Projekten. Aus diesem riesigen Pool wählten sie zufällig fünfzigtausend Kommentare für eine manuelle Untersuchung aus. Diese manuelle Überprüfung war mühsame Arbeit, die es den Forschern erforderte, jede Notiz zu lesen und zu entscheiden, ob sie ein echtes Geständnis eines Problems oder nur eine Standarderklärung darstellte. Nach dem Filtern von Kommentaren, die nicht relevant waren oder aus einem einzelnen Projekt stammten, das die Daten verzerrt hätte, identifizierten sie 615 Kommentare, die echte Beispiele für technische Schulden im Testcode waren.

Die Forscher entdeckten, dass die Art dieser Schulden im Testcode quite anders ist als das, was im Hauptanwendungscode zu finden ist. Sie sortierten die 615 Instanzen in elf verschiedene Kategorien ein. Einige davon waren vertraut, wie etwa Notizen über schlechtes Design oder fehlende Dokumentation. Vier Kategorien waren jedoch völlig neu und spezifisch für die Welt des Testens. Dazu gehörten „limitierte Tests“, bei denen ein Entwickler zugibt, dass der Test nur einen winzigen, nicht repräsentativen Ausschnitt des Problems prüft; „Skip-Tests“, bei denen ein Test explizit deaktiviert wurde, weil er in der aktuellen Umgebung nicht laufen kann; „On-hold“, wo ein Test auf ein externes Tool oder einen Dienst wartet, der verfügbar werden muss; und „Unsicherheit“, bei der der Entwickler sich unsicher ist, ob der Test überhaupt korrekt ist. Diese Taxonomie verdeutlichte, dass Testcode seine eigenen einzigartigen Lasten trägt, die oft mit den spezifischen Herausforderungen der Validierung von Softwareverhalten zusammenhängen, statt mit deren Aufbau.

Nachdem sie kartografiert hatten, wie diese Schulden aussehen, stellten die Forscher eine zweite, praktischere Frage: Können Computer sie automatisch finden? Sie testeten sieben bestehende Tools, die darauf ausgelegt sind, diese Notizen in regulärem Quellcode aufzuspüren. Sie testeten auch eine Reihe von Modellen der Künstlichen Intelligenz, einschließlich sowohl Open-Source-Modelle als auch leistungsstarker, proprietärer Systeme von großen Technologieunternehmen. Die Ergebnisse waren überraschend. Die bestehenden Tools, die darauf basieren, nach spezifischen Schlüsselwörtern wie „TODO“ oder „FIXME“ zu suchen, schnitten unter den traditionellen Methoden am besten ab, übersehenen aber immer noch mehr als ein Drittel der tatsächlichen Schulden. Sie waren gut darin, korrekt zu sein, wenn sie etwas fanden, aber sie versäumten es, viele der realen Probleme zu finden.

Die Modelle der Künstlichen Intelligenz schnitten in anderer Hinsicht sogar schlechter ab. Die Open-Source-Modelle hatten Schwierigkeiten, die Schulden überhaupt zu finden, und erkannten sie oft nicht, sofern die Notizen keine sehr offensichtlichen Schlüsselwörter enthielten. Wenn sie etwas fanden, lagen sie häufig falsch. Die proprietären Modelle, die im Allgemeinen als fortsrittlicher gelten, zeigten das gegenteilige Problem. Sie fanden fast jede einzelne Schuld, markierten aber auch hunderte harmlose Kommentare als Probleme. Sie waren so darauf bedacht, Probleme zu finden, dass sie gewöhnliche Erklärungen als Eingeständnisse eines Fehlers missverstanden. Letztendlich konnte weder das traditionelle Werkzeug noch das fortschrittlichste KI-System diese Schulden im Testcode zuverlässig erkennen.

Die Studie kommt zu dem Schluss, dass die Art und Weise, wie Entwickler über Probleme im Testcode schreiben, sich grundlegend von der Art unterscheidet, wie sie über Probleme im Hauptcode schreiben. Die Notizen in Testdateien verwenden oft eine Sprache, die spezifisch für den Testprozess ist, wie etwa die Erwähnung, dass ein Test „deaktiviert“ oder „übersprungen“ wurde, was Standard-Tools und KI-Modelle nicht als Zeichen von Schulden erkennen. Die Forscher stellten fest, dass aktuelle Methoden noch nicht bereit sind, diese Komplexität zu bewältigen. Sie haben einen neuen Datensatz und eine detaillierte Karte dieser Schuldentypen erstellt, um zukünftige Forscher beim Aufbau besserer Erkennungswerkzeuge zu unterstützen. Bis dahin bleibt die Aufgabe, diese verborgenen Mängel im Testcode zu finden und zu beheben, eine Arbeit, die menschliche Aufmerksamkeit erfordert.