Las pruebas existentes de la interfaz de usuario de Android dejaron de funcionar después de cambiar a AndroidJUnitRunner

Tenemos algunas pruebas de interfaz de usuario alrededor de nuestra funcionalidad de cámara, y después de hacer el cambio de InstrumentationTestRunner a AndroidJUnitRunner como parte de nuestro paso a Espresso / JUnit4, ya no podemos ejecutar nuestras pruebas existentes de forma fiable debido a RuntimeException frecuente cuando llamamos getActivity() :

 java.lang.RuntimeException: Could not launch intent Intent { flg=0x14000000 cmp=com.cookbrite.dev/com.cookbrite.ui.ReceiptCaptureActivity (has extras) } within 45 seconds. Perhaps the main thread has not gone idle within a reasonable amount of time? There could be an animation or something constantly repainting the screen. Or the activity is doing network calls on creation? See the threaddump logs. For your reference the last time the event queue was idle before your activity launch request was 1434471981236 and now the last time the queue went idle was: 1434471981236. If these numbers are the same your activity might be hogging the event queue. at android.support.test.runner.MonitoringInstrumentation.startActivitySync(MonitoringInstrumentation.java:315) at android.test.InstrumentationTestCase.launchActivityWithIntent(InstrumentationTestCase.java:119) at android.test.ActivityInstrumentationTestCase2.getActivity(ActivityInstrumentationTestCase2.java:106) at com.cookbrite.step2_functional.ui.receipt.ReceiptCaptureTest.getActivity(ReceiptCaptureTest.java:43) 

Para una mejor legibilidad, este es el mensaje de error en RuntimeException como una cotización:

No se pudo iniciar intención Intent {flg = 0x14000000 cmp = com.cookbrite.dev / com.cookbrite.ui.ReceiptCaptureActivity (tiene extras)} en 45 segundos. Tal vez el hilo principal no ha ido inactivo dentro de una cantidad razonable de tiempo? Podría haber una animación o algo constantemente repintando la pantalla. ¿O la actividad está haciendo llamadas de red en la creación? Vea los registros de la caché. Para su referencia, la última vez que la cola de eventos estuvo inactiva antes de que su solicitud de lanzamiento de actividad fuera 1434471981236 y ahora la última vez que la cola quedó inactiva fue: 1434471981236. Si estos números son iguales, su actividad podría acaparar la cola de eventos.

Nuestras pruebas existentes utilizan Robotium. Un intento de escribir la misma prueba usando Espresso produjo un error similar, lo que probablemente se deba a la previsualización de la cámara constantemente actualizando la interfaz de usuario. Sin embargo, incluso con la vista previa fijada a INVISIBLE , todavía nos topamos con este problema con Espresso.

Cualquier ideas / punteros sobre cómo arreglar esto (aparte de volver a InstrumentationTestRunner )?

La salida de error indica que la clase de prueba extiende ActivityInstrumentationTestCase2 . No estoy seguro de si mover a la nueva ActivityTestRule haría cualquier diferencia en su caso, pero vale la pena una revisión rápida. Poner esto en una respuesta en lugar de un comentario para incluir código de ejemplo:

 @RunWith(AndroidJUnit4.class) public class ReceiptCaptureTestNew { private ReceiptCaptureActivity mReceiptCaptureActivity; @Rule public ActivityTestRule<mReceiptCaptureActivity> mActivityRule = new ActivityTestRule<>(mReceiptCaptureActivity.class); @Before public void setUp() throws Exception { mReceiptCaptureActivity = mActivityRule.getActivity(); } @After public void tearDown() throws Exception { // Call finish() on all activities in @After to avoid exceptions in // later calls to getActivity() in subsequent tests mReceiptCaptureActivity.finish(); } @Test public void testPreconditions() { assertNotNull(mReceiptCaptureActivity); assertThat(mReceiptCaptureActivity.hasWindowFocus(), is(true)); } } 

Al final, cambiamos la interfaz de usuario para retrasar el inicio de la previsualización de la cámara para que MonitoringInstrumentation no se altere con la actualización de la UI. Además, tanto SurfaceView como TextureView post UI actualizaciones tan pronto como una cámara está conectada, incluso en estado INVISIBLE o GONE . Eso es lo que hace que MonitoringInstrumentation abandone en nuestro caso.

Si tiene una prueba que empiece con una actualización constante de la interfaz de usuario, puede considerar detener la acción hasta que startActivitySync() y obtenga un resultado no nulo de getActivity() .

  • BDD Android UI marco de pruebas?
  • Android Testing - Problema con ActivityInstrumentationTestCase2?
  • No se puede ejecutar Robotium en Android Studio con sólo APK
  • Prueba de interfaz de usuario de Robotium para la aplicación con el cajón de navegación
  • Android: Colaboración de la interfaz de usuario (Jenkins + Spoon +?)
  • ¿Cómo averiguar qué actividad está encima de la pila usando Robotium / Android SDK?
  • Utilice tanto InstrumentationTestRunner como AndroidJUnitRunner con Robotium y Espresso
  • Crear prueba Android apk utilizando el sistema de compilación gradle
  • Ejemplos de Robotium
  • El módulo de prueba de instrumentos de gradación Android no ve las fuentes del proyecto principal
  • Comprobar la existencia de un fragmento usando Robotium - Android
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.