Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Pruebas de unidad de Android con múltiples subprocesos

Tengo un problema con las pruebas de unidad en Android.

Mi objeto MyObject tiene un método start() así:

 public void start() { final Handler onStartHandler = new Handler(); new Thread() { @Override public void run() { super.run(); onStartHandler.post(new Runnable() { @Override public void run() { mIsRunning = true; onStart(); } }); } }.start(); } 

Y quiero probar que onStart () se llama. Así que probé algo así:

 public void testOnStartIsCalled() { assertFalse("onStart() should not be called", mMyObject.isRunning()); mMyObject.start(); assertTrue("onStart() should be called", mMyObject.isRunning()); mMyObject.stop(); assertFalse("onStop() should be called", mMyObject.isRunning()); } 

Pero no funciona, supongo que es porque está en un Handler y un nuevo Thread.

Mi clase de prueba extiende AndroidTestCase. Que debería hacer ? ¿Cuál es la mejor práctica para este caso?

Saludos.

2 Solutions collect form web for “Pruebas de unidad de Android con múltiples subprocesos”

Cuando trato de probar un código de varios hilos intento dejar que el programa tome tanto de su flujo natural como sea posible. Además, evito el uso de declaraciones de sueño ya que no obtiene ninguna garantía de que el intervalo de sueño que ha elegido es suficiente para permitir que el sujeto de su prueba para terminar lo que está haciendo, A menudo terminan teniendo que elegir intervalos de sueño que son demasiado grandes y obliga a una ejecución mucho más lenta de sus casos de prueba.

Yo recomendaría que intentes agregar algún código a la clase que estás probando, en este caso MyObject , que llama a un oyente siempre que algo sucede. Parece que ya tienes los métodos de devolución de llamada para onStart() y onStop() (si son eventos / callbacks), por lo que deberían invocarse y deberían utilizarse para controlar el flujo de la prueba. Cuando recibe un evento onStart() , debe llamar a stop() y esperar un evento onStop() .

Actualizar

En primer lugar, tiene código redundante:

 public void start() { final Handler onStartHandler = new Handler(); new Thread() { @Override public void run() { super.run(); onStartHandler.post(new Runnable() { @Override public void run() { mIsRunning = true; onStart(); } }); } }.start(); } 

onStart() un nuevo subproceso para invocar onStart() o programe el ejecutable en la cola de subprocesos del controlador.

Versión 1: quite el controlador y simplemente deje que el código se ejecute en un nuevo subproceso:

 public void start() { new Thread() { @Override public void run() { super.run(); mIsRunning = true; onStart(); } }.start(); } 

La versión 2 sólo utiliza el controlador para ejecutar asincrónicamente la devolución de llamada:

 public void start() { final Handler onStartHandler = new Handler(); onStartHandler.post(new Runnable() { @Override public void run() { mIsRunning = true; onStart(); } }); } 

Y en segundo lugar: me di cuenta es que si no tienes un Looper , entonces lo que se publique con el Handler será ignorado (por lo que nunca se llamará). Para obtener más información sobre el patrón Looper-Handler, consulte el artículo: Android Guts: Intro to Loopers and Handlers . Se supone que el Looper y el Handler están conectados al mismo hilo (normalmente el hilo principal). Además, si está creando el Handler en un hilo separado como Looper , se ejecutará en el mismo problema: cualquier cosa que se publique con el Handler se ignorará.

Aquí hay algunas preguntas más buenas y artículos sobre bucleadores y manipuladores:

  • Simplemente hágalo: looper and handler in android
  • Implementación de Handler-Looper en Android

Las relaciones entre Looper, Handler y MessageQueue se muestran a continuación: Introduzca aquí la descripción de la imagen

El problema aquí es que estás llamando a onStart () que invoca un nuevo hilo, y luego pregunta inmediatamente si se inicia. Hay tiempo de inicio para el nuevo hilo y mientras eso sucede, su prueba está preguntando si se ha iniciado – aún no es.

Apuesto a que si esperó con Thread.sleep (), o un bucle, se encuentra que se inicia "eventualmente".

¿Qué es lo que realmente estás tratando de probar?

Si necesita el nuevo hilo, puede que desee leer sobre temas, sincronizar, etc. http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.