0
479
VistasLa prueba de instrumentación de navegación de Android lanza el método addObserver debe llamarse en el subproceso principal
Tengo dos fragmentos, uno de los cuales es un fragmento de inicio en mi gráfico. Se navegará al usuario al segundo fragmento al hacer clic en un botón. Funciona como se esperaba al llevar al usuario al segundo fragmento y mostrar el texto. Así que el gráfico es bueno.
Ahora quería escribir una prueba de instrumentación.
@RunWith(AndroidJUnit4::class) class TransitionTest { @Test fun testNavigationToSecondFragment() { val navController = TestNavHostController( ApplicationProvider.getApplicationContext()) navController.setGraph(R.navigation.my_graph) <--throws exception // the rest of my test continues here } }Sin embargo, la línea que se muestra arriba para configurar el gráfico arroja la siguiente excepción:
IllegalStateException: se debe llamar al método addObserver en el subproceso principal.
Mi entorno:
fragment_version = 1.2.5 nav_version = 2.3.1 espresso = 3.3.0
¿Alguien tiene alguna idea de lo que está pasando y cómo solucionarlo?
4 Respuestas
Responde la pregunta0
Me enfrenté a lo mismo, así que intentaré explicar la causa raíz de esto. A partir de androidx.lifecycle:lifecycle-*:2.3.0-alpha06 . Hay un cambio de comportamiento en LifecycleRegistry . LifecycleRegistry ahora verifica que sus métodos se llamen en el subproceso principal. Ahora queda otra pregunta sin resolver si las pruebas de instrumentación se ejecutan en MainThread. Aparentemente no, de lo contrario hubiera pasado. Está utilizando Instrumentation Thread donde se ejecutan la mayoría de las pruebas. Según la documentación, puede usar @UiThreadTest o runOnUiThread como en la respuesta superior.
0
Empecé a tener este problema también, después de actualizar el paquete:
implementation 'androidx.activity:activity:1.2.0-alpha06'para
implementation 'androidx.activity:activity:1.2.0-beta01'En mi código estoy abriendo un Fragmento en un subproceso de fondo, y esto parece romperse con el nuevo paquete. El fragmento agrega un observador durante el ciclo de vida:
Creo que su solución alternativa de envolver la llamada para que se ejecute en el subproceso de la interfaz de usuario es la única solución plausible, ya que el observador también se puede agregar internamente en su caso.
0
Envolví la función setGraph en runOnUiThread como tal y la prueba pasó. Actualizaré la respuesta una vez que descubra la causa real y una mejor solución.
runOnUiThread { navController.setGraph(R.navigation.my_graph) }0
Hay una solución más para resolver el problema usando este
InstrumentationRegistry.getInstrumentation().runOnMainSync { navController.setGraph(R.navigation.my_graph) } Dado que @UiThreadTest solo funciona en @Test , @Before y @After , si tiene alguna función de prueba común, es posible que no funcionen como se esperaba.