Manera correcta de usar IdlingResource en Espresso Android

Estoy escribiendo pruebas de UI con Espresso. La aplicación coopera estrechamente con el servidor, por lo que en muchos casos, necesito esperar que se calculen los valores, o se obtienen los datos, etc. Espresso sugiere usar IdlingResource para esto. Mis clases de IdlingResource se parecen a esto (ejemplo simple y claro).

public class IRViewVisible implements IdlingResource { private View view; private ResourceCallback callback; public IRViewVisible(View view) { this.view = view; } @Override public String getName() { return IRViewVisible.class.getName(); } @Override public boolean isIdleNow() { if(view.getVisibility() == View.VISIBLE && callback != null) { callback.onTransitionToIdle(); return true; } return false; } @Override public void registerIdleTransitionCallback(ResourceCallback resourceCallback) { this.callback = resourceCallback; } }

Por favor, corrija si estoy equivocado en alguna parte (ya que a veces me parece que mis IdlingResources no funcionan correctamente). Registro el recurso setUp() en setUp() así:

 IRViewVisible ir = new IRViewVisible(View v); Espresso.registerIdlingResources(ir).

Desregistrarlo en tearDown ().

He encontrado este artículo (hay una sección llamada "Registrar un componente vinculado a una instancia de actividad") – No uso su esquema, pero he comprobado hashcode de vista que se estableció a IdlingResource después de registrarse (en cada método), y es No la misma vista – todos los hashes son diferentes.

Otra pregunta: Una clase de prueba (sus resultados) no puede tener ningún efecto en otra clase de prueba, ¿no?

Supongo que su problema proviene de getName() devolviendo el mismo nombre para todas las instancias de IRViewVisible. Esto significa que sólo puede tener una instancia registrada de la misma a la vez – cualquier registro subsiguiente fallará (en silencio!).

Menciona que borra los IdlingResources al final de cada prueba, pero si está registrado varias instancias de una vez, debe asegurarse de que cada instancia tenga un nombre único. No está claro de su pregunta si está registrando varias instancias de IRViewVisible en una sola prueba .

En cuanto a su pregunta final: Sí, es posible. Android no cierra completamente la Aplicación entre pruebas, solo las Actividades. Cosas comunes que pueden causar problemas:

No se puede borrar el estado persistente (datos guardados).
No se puede borrar el estado global, por ejemplo, variables estáticas / singletons
No está esperando que los subprocesos de fondo terminen de ejecutarse.

Como un aparte, vale la pena señalar que sólo se llama onTransitionToIdle() dentro de isIdleNow() . Esto funciona (gracias @Be_Negative para la cabeza!), Pero podría ralentizar sus pruebas mucho, ya que Espresso sólo encuesta isIdleNow() cada pocos segundos. Si llama a onTransitionToIdle() tan pronto como la vista se vuelve visible, debería acelerar las cosas considerablemente.

Necesitaba algo similar a su IRViewVisible yo mismo, aquí está mi esfuerzo .

Bueno, en primer lugar, no deberías usar Espresso IdlingResource para probar las llamadas al servidor. Si utiliza AsyncTask en sus llamadas al servidor, Espresso podrá saber cuándo estar inactivo y cuándo no. Si esto no es suficiente: trate de refactorizar su código de esta manera:

  IRViewVisible idlingResource = new IRViewVisible(yourView); IdlingPolicies.setMasterPolicyTimeout(waitingTime * 2, TimeUnit.MILLISECONDS); IdlingPolicies.setIdlingResourceTimeout(waitingTime * 2, TimeUnit.MILLISECONDS); // Now we wait Espresso.registerIdlingResources(idlingResource); // Stop and verify // Clean up Espresso.unregisterIdlingResources(idlingResource);

Espero ser útil.

Por lo tanto, el método isIdleNow () nunca devolverá true si no establece una devolución de llamada a idlingResource? Creo que es mejor refactorizarlo así:

 @Override public boolean isIdleNow() { boolean idle = view.getVisibility() == View.VISIBLE; if(idle && callback != null) { callback.onTransitionToIdle(); } return idle; }