Wir haben einige UI-Tests in Bezug auf unsere Kamerafunktionalität, und nachdem wir im Zuge unseres Umzugs auf Espresso / JUnit4 von InstrumentationTestRunner auf AndroidJUnitRunner gewechselt haben, können wir unsere bestehenden Tests nicht mehr zuverlässig ausführen, weil sie häufig sind RuntimeException, wenn wir getActivity() aufrufen:
Zur besseren Lesbarkeit ist dies die Fehlermeldung in der RuntimeException als Zitat:
Absicht konnte nicht gestartet werden {flg = 0x14000000 cmp = com.cookbrite.dev / com.cookbrite.ui.ReceiptCaptureActivity (hat Extras)} innerhalb von 45 Sekunden. Vielleicht ist der Hauptthread nicht ungenutzt geblieben innerhalb einer angemessenen Zeit? Es könnte eine Animation geben oder etwas, das den Bildschirm ständig neu streicht. Oder die Aktivität tut Netzwerk ruft bei der Erstellung auf? Siehe die Threaddump-Protokolle. Zu Ihrer Information das letzte Mal, als die Ereigniswarteschlange vor dem Start Ihrer Aktivität inaktiv war Anfrage war 1434471981236 und jetzt das letzte Mal, als die Warteschlange untätig wurde war: 1434471981236. Wenn diese Zahlen die gleichen sind, könnte Ihre Aktivität die Ereigniswarteschlange in den Griff zu bekommen.
Unsere bestehenden Tests verwenden Robotium. Ein Versuch, den gleichen Test mit Espresso zu schreiben, ergab ähnliche Fehler, was wahrscheinlich darauf zurückzuführen ist, dass die Kameravorschau die Benutzeroberfläche ständig aktualisiert. Auch wenn die Vorschau auf INVISIBLE eingestellt ist, stoßen wir dennoch auf dieses Problem mit Espresso.
Irgendwelche Ideen / Hinweise, wie man das beheben kann (außer zu InstrumentationTestRunner zurückgehen)?
Am Ende ändern wir die Benutzeroberfläche, um den Start der Kameravorschau zu verzögern, damit MonitoringInstrumentation nicht mit der gesamten UI-Aktualisierung verärgert wird. Außerdem melden sowohl SurfaceView als auch TextureView UI-Aktualisierungen, sobald eine Kamera verbunden ist, auch in INVISIBLE oder GONE state. Das bewirkt, dass MonitoringInstrumentation in unserem Fall aufgibt.
Wenn Sie einen Test haben, der mit einer konstanten UI-Aktualisierung beginnt, sollten Sie in Betracht ziehen, die Aktion anzuhalten, bis startActivitySync() beendet ist und Sie ein Ergebnis ungleich null von getActivity() erhalten.
Die Fehlerausgabe zeigt an, dass die Testklasse ActivityInstrumentationTestCase2 erweitert. Ich bin mir nicht sicher, ob der Wechsel zu der neuen ActivityTestRule in Ihrem Fall einen Unterschied machen würde, aber es ist eine schnelle Überprüfung wert. Setzen Sie dies in eine Antwort statt in einen Kommentar ein, um Beispielcode einzufügen:
Tags und Links android robotium android-testing