Änderungen, die Tests und Code zusammen anfassen, werden seltener zurückgenommen als reine Code-Änderungen ähnlicher Grösse

Hypothese

Repositories halten ihre eigenen zweiten Gedanken fest: Die git-revert-Dokumentation beschreibt den Befehl als das Aufzeichnen neuer Commits, die die Wirkung früherer aufheben, und Korrekturcommits verweisen in ihrer Nachricht oft auf die Änderung, die sie beheben. Die Hypothese lautet, dass unter Änderungen ähnlicher Grösse im selben Bereich einer Codebasis jene, die Testdateien zusammen mit Produktionscode hinzufügen oder ändern, innerhalb eines kurzen Zeitfensters seltener zurückgenommen oder korrigiert werden als Änderungen, die nur Produktionscode anfassen. Der vorgeschlagene Mechanismus ist nicht, dass Tests jeden Fehler abfangen, sondern dass das Schreiben oder Anpassen eines Tests die Autorin oder den Autor zwingt, festzulegen, was die Änderung tun soll, und sie einmal in dieser Form auszuführen, was eine Klasse von Fehlern (falscher Branch, falscher Default, vergessene Aufrufstelle) vor dem Review beseitigt.

Vorhersage

Für ein Repository mit funktionierender Testsuite ist der Anteil der Änderungen, denen innerhalb eines definierten Zeitfensters (zum Beispiel 14 Tage) ein Revert dieser Änderung folgt oder ein Commit, dessen Nachricht sie als Fix referenziert, nach Abgleich nach geänderten Zeilen, betroffenen Dateien und Verzeichnis niedriger bei Änderungen, die Testdatei-Modifikationen enthalten, als bei reinen Code-Änderungen. Der Unterschied dürfte bei trivialen Änderungen (Umbenennungen, Kommentaränderungen) kleiner ausfallen und bei Änderungen an Logik mit Verzweigungen grösser. Änderungen, die nur Testdateien anfassen, werden aus beiden Gruppen ausgeschlossen.

Vorgeschlagener Test

1. Repositories mit einer in CI laufenden Testsuite und einer Geschichte von mindestens einem Jahr auswählen; Testdateien pro Repository anhand eines Pfadmusters definieren.
2. Für jede Nicht-Merge-Änderung Grösse, Dateien, Verzeichnis, ob Testdateien geändert wurden, und die Autorin oder den Autor festhalten.
3. „Bereute“ Änderungen identifizieren: ein späterer git revert der Änderung oder ein Commit innerhalb des Zeitfensters, dessen Nachricht die Kennung der Änderung mit fixähnlicher Formulierung referenziert; die Erkennungsregel festhalten.
4. Reine Code-Änderungen und Code-plus-Test-Änderungen nach Grösse und Verzeichnis abgleichen; die Bereuensraten mit einem Intervall vergleichen und dies pro Repository wiederholen, statt die Daten zusammenzulegen.
5. Den Anteil der Änderungen berichten, die überhaupt Tests anfassten, da ein Repository, in dem fast jede Änderung das tut, keinen Kontrast liefert.

Status

Es wird kein Ergebnis behauptet. Reverts sind ein enges Signal: Viele schlechte Änderungen werden ohne jeden Verweis vorwärts korrigiert, und manche Reverts haben nichts mit Fehlern zu tun (ein aus Produktgründen zurückgezogenes Feature). Der Abgleich nach Grösse ist wesentlich, weil grössere Änderungen sowohl eher Tests enthalten als auch eher zurückgenommen werden, was in beide Richtungen ein Scheinergebnis erzeugen könnte.