2010-11-01 8 views
11

Tal vez me esté perdiendo algo. Quiero escribir casos de prueba para un BroadcastReceiver; específicamente, es para recibir el evento BOOT_COMPLETED y configurar una alarma para que otro receptor la maneje más tarde; no parece estar configurándolo correctamente, pero el punto es que no tengo una forma obvia de probarlo. No puedo adjuntar exactamente un depurador y esperar BOOT_COMPLETED, y no puedo enviar una transmisión BOOT_COMPLETED falsa.¿Por qué no hay instrumentación de prueba para BroadcastReceiver?

¿Por qué hay clases de instrumentación para Actividad, Servicio y Proveedor, pero no BroadcastReceiver? Algún consejo para probar esto?

Respuesta

18

No hay nada de mágico en el ciclo de vida de BroadcastReceiver. Es suficiente probarlo con una AndroidTestCase. En un caso de prueba, crea una instancia de tu BroadcastReceiver, crea la intención que quieras enviar y llámalaRecibe utilizando el contexto disponible de AndroidTestCase o algún contexto de simulacro.

E.g.

public class TestMyBroadcastReceiver extends AndroidTestCase { 
    public void testReceive() { 
    MyBroadcastReceiver r = new MyBroadcastReceiver(); 
    Intent i = new Intent("MY_ACTION"); 
    // TODO put extras 
    r.onReceive(getContext(), i); 
    // TODO query application state to verify results 
    } 
} 
+0

simple y hace el trabajo! – Robert

7

Para la mayoría de los casos estoy completamente de acuerdo con https://stackoverflow.com/a/5181010/527016

Sin embargo, hay casos en los que se extiende AndroidTestCase no es adecuado (y puede causar sorpresas). En particular, si está realizando pruebas de integración más complejas y desea probar su BroadcastReceiver con un Intent real enviado por el sistema. La razón principal es que el método onReceive en el receptor de difusión se ejecuta en el subproceso principal de la aplicación mientras que las pruebas en AndroidTestCase se ejecutan en otro subproceso. Esto puede causar problemas de subprocesamiento relacionados con la prueba en el código que no se intentó ejecutar en varios subprocesos.

La solución a esto es una subclase de la prueba de InstrumentationTestCase lugar y utilizar la anotación @UiThreadTest para hacer las pruebas se ejecutan en el mismo subproceso como el método onReceive.

Para obtener más información (y un ejemplo) ver: http://olafurhelgason.blogspot.com/2012/12/threading-and-android-integration.html

Cuestiones relacionadas