Codequalität und Zuverlässigkeit

Diese Zahlen sind nicht der Ausgangspunkt gewesen. Der erste Mutationstest-Durchlauf am größten und schwierigsten Modul (dem Python-Interpreter, ~2500 Zeilen) ergab 75,65 % — knapp ein Viertel der absichtlich eingeschleusten Defekte blieb also völlig unbemerkt. Diese Lücke auf 100 % zu schließen, brauchte sieben aufeinanderfolgende Durchläufe, die jeweils einen Teil des Rests schlossen und dabei neue Grenzfälle offenlegten — einschließlich Methodikfehlern, die während des Prüfprozesses selbst gemacht wurden.

Echte Anwendungsfehler gefunden und behoben (nicht nur Testlücken) — genau durch diesen gründlichen Prozess aufgedeckt: Die Punktzahl einer Lektion wurde nach einer korrigierten Falschantwort fälschlich zu niedrig angesetzt (ein einziger Fehler begrenzte die maximal mögliche Punktzahl dauerhaft, selbst wenn die Lernperson beim Wiederholen sofort richtig antwortete); der Einstufungstest vergab fälschlich die Erfolge „Fehlerfrei" und „Keine Gnade" für übersprungene, nicht wirklich abgeschlossene Lektionen; sowie drei eng begrenzte Bugs im Interpreter selbst (Ganzzahldivision, Rundung beim Restwert-Operator, Vergleich von bool mit int).

Ein Methodikfehler wurde mitten im Prozess entdeckt und korrigiert: Eine zwischenzeitliche Verifikationsmethode (Ersetzen des gesamten Zeilentexts statt Mutation an Strykers exakten Koordinaten) überschätzte, wie viele Mutanten tatsächlich „äquivalent" (also unlösbar) waren — von 35 solchen Annahmen bestätigte sich nur 1. Behoben durch Umstellung auf präzise, koordinatengenaue Verifikation für jeden Einzelfall.

Die letzten 5 Mutanten (String-Vergleich für das Sortieren von Listen) widerstanden sowohl einem Äquivalenzbeweis als auch jedem Test über die normale öffentliche Schnittstelle — der native Sortieralgorithmus von JavaScript führt redundante Vergleiche durch, die ein einzelnes falsches Paar-Ergebnis maskieren, selbst bei einer rückwärts sortierten 5-Elemente-Liste. Gelöst durch direktes Testen der internen Vergleichsfunktion, unter vollständiger Umgehung des unvorhersehbaren Verhaltens des fremden Sortieralgorithmus.

Fazit: Keine Zahl in diesem Bericht ist geschönt. Jede ist das Ergebnis iterativer, verifizierter Arbeit — einschließlich des Eingeständnisses und der Korrektur eigener Fehler unterwegs. Genau deshalb ist diesen Zahlen zu trauen: Die App verhält sich nicht nur bei den geprüften Beispielen korrekt — das Sicherheitsnetz der Tests drumherum erkennt künftige Regressionen tatsächlich, statt nur formal zu existieren.

Warum aus „2797 von 2797, 100%" kurzzeitig „3373 von 3374, 99,97%" wurde, bevor es wieder 100% waren: Nachdem zuerst 100% erreicht waren (oben), bekam der Interpreter neue Kursthemen dazu — direkte Iteration (for x in iterable: ohne range()), __str__/__eq__, @staticmethod/@classmethod, Dictionaries/Sets/Comprehensions/Generatoren — Hunderte neuer Zeilen, die noch nie durch Mutationstests gelaufen waren. Statt dieses Wachstum ungeprüft zu lassen (und stillschweigend weiter ein veraltetes „100%" anzuzeigen), wurde es genauso gründlich durch Stryker geschickt wie alles andere: 32 neue Regressionstests, jeder gegen einen konkreten überlebenden Mutanten geschrieben (erst den Code drumherum gelesen, logisch nachvollzogen, warum die bestehenden Tests ihn übersehen hatten, und erst dann den Test geschrieben) — keine Coverage-Auffüllung. Alles andere, was sich seit dem vorigen Mutationstest-Durchlauf (17. August) geändert hatte, wurde ebenfalls geprüft: der Parser (neue Grammatik für dieselben neuen Themen) und der Wiederholungsplaner (ein neuer Schwellenwert vor dem Interleaving) — beide bereits bei 100%, ohne weiteren Aufwand. Damit blieb genau ein Mutant ungelöst, und an dieser Stelle stand im Bericht kurzzeitig „3373 von 3374, 99,97%" — mit einer Erklärung, warum das ehrlicher ist als ein herbeigeführtes „100%": Eine Funktion zum Nachschlagen lokaler Variablen (Scope.tryGet) enthielt eine Prüfung, die theoretisch in zwei unterschiedlichen Szenarien relevant sein könnte, von denen sich eines angesichts jeder tatsächlichen Aufrufstelle in der App als mathematisch unmöglich erwies — und das andere, tatsächlich erreichbare Szenario war bereits durch einen eigenen Test abgedeckt. Beide Mutanten dieser Zeile mit einem einzigen Kommentar als „äquivalent" zu markieren, wäre der schnellste Weg zu „100%" gewesen — genau deshalb wurde es damals nicht getan: Das Werkzeug kann die Mutationsprüfung nur für eine ganze Zeile deaktivieren, nicht für einen einzelnen Mutanten, sodass diese Abkürzung auch die Abdeckung für das tatsächlich relevante Szenario weggewischt hätte.

Was danach geschah — und warum das echte 100% sind, kein Workaround: Statt sich mit 99,97% zufriedenzugeben oder den Rest still zu unterdrücken, lautete die nächste Frage, ob diese Zeile von vornherein toter Code war. Eine genauere Nachverfolgung jedes Aufrufs von tryGet() in der App (es gibt genau einen) und jeder Stelle, von der der von ihr geschützte Wert überhaupt stammen konnte, zeigte: ja — die Zeile war in jedem realen Programmzustand tatsächlich unerreichbar, nicht bloß schwer zu testen. Sie wurde vollständig entfernt. Das ist kein Trick: Das Löschen von wirklich totem Code kostet keine echte Abdeckung (anders als das Unterdrücken des Mutanten per Kommentar, das auch die echte, bereits verifizierte Abdeckung des Schwester-Mutanten weggeworfen hätte) — der Mutant, den diese Zeile erzeugte, hörte einfach zusammen mit ihr auf zu existieren. Die vollständige Testsuite (damals 1035 Tests) bestätigte, dass sich das Verhalten nicht im Geringsten änderte. Der nächste Stryker-Durchlauf ergab ein echtes 100,00%. Die Lehre aus diesem kleinen Umweg im Bericht selbst: Die Bereitschaft, eine ehrliche Zahl knapp unter 100% zu zeigen, erwies sich als der schnellere Weg zu einem echten 100% — nicht als langsamerer, als die Lücke von Anfang an zu übertünchen.

Woher das Wachstum von 3371 auf 3694 und von 9655 auf 9710 kommt (1. September 2026): Der Kurs ist gewachsen — ein neues 17. Modul, „Import, Module und Dateiverarbeitung", brachte echte (nicht nur syntaktisch erkannte) Ausführung von import/open()/with gegen ein simuliertes virtuelles Dateisystem, und ein neuer Abschnitt „Lifehacks" (15 „Vorher → Nachher"-Karten mit Erklärung, warum die kürzere Schreibweise dasselbe leistet). Beide Ergänzungen durchliefen dieselbe Disziplin wie der Rest der App: interpreter.ts und parser.ts wurden erneut durch Mutationstests geschickt (+238 bzw. +36 Mutanten, alle erkannt), der neue lifehacks-engine und manage-lifehacks wurden von null auf 100% gebracht (2 echte Testlücken geschlossen, nicht überdeckt), alle 15 Karten (30 Code-Schnappschüsse) wurden gegen CPython geprüft, ebenso die 2 neuen schleifenbasierten Übungen aus Modul 17. Am selben Tag wurde außerdem der letzte Übersetzungsrückstand geschlossen: Der Abschnitt „Lifehacks" und alle 434 neuen Schlüssel aus Modul 17 wurden sofort ins Spanische, Französische, Deutsche und Portugiesische übersetzt, sodass alle 6 Kurssprachen jetzt bei 100% Inhaltsparität liegen (12 214 Schlüssel pro Sprache) — daher stammt auch das Wachstum der Lokalisierungsvergleiche von 58 635 auf 61 070.