Pourquoi n'y a-t-il pas d'instrumentation de test pour BroadcastReceiver?

Question

Peut-être qu'il me manque quelque chose. Je veux écrire des cas de test pour un BroadcastReceiver; spécifiquement, c'est pour recevoir l'événement BOOT_COMPLETED et régler une alarme pour un autre récepteur à gérer plus tard; il ne semble pas le régler correctement, mais le fait est que je n'ai aucun moyen évident de le tester. Je ne peux pas attacher un débogueur et attendre BOOT_COMPLETED, et je ne peux pas envoyer une fausse émission BOOT_COMPLETED.

Pourquoi existe-t-il des classes d'instrumentation pour Activity, Service et Provider, mais pas BroadcastReceiver? Des conseils pour tester cela?

Answer 1

Il n'y a rien de magique dans le cycle de vie du BroadcastReceiver. Il suffit de le tester avec un AndroidTestCase. Dans un scénario de test, instanciez votre BroadcastReceiver, créez l'intention que vous voulez envoyer et appelez onReceive en utilisant le contexte disponible sur AndroidTestCase ou un faux contexte.

Par ex

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 
    } 
} 

Answer 2

Pour la plupart des cas, je suis entièrement d'accord avec https://stackoverflow.com/a/5181010/527016

Il y a cependant des cas lors de l'extension AndroidTestCase ne convient pas (et peut causer des surprises). En particulier, si vous faites des tests d'intégration plus complexes et que vous voulez tester votre BroadcastReceiver avec un Intent réel envoyé par le système. La raison principale est que la méthode onReceive dans le récepteur de diffusion s'exécute sur le thread d'application principal tandis que les tests dans AndroidTestCase s'exécutent dans un autre thread. Cela peut provoquer des problèmes de thread liés au test dans du code qui n'était pas destiné à être exécuté sur plusieurs threads.

La solution est de sous-classe votre test de InstrumentationTestCase au lieu et utiliser l'annotation @UiThreadTest pour effectuer les tests effectués sur le même fil que la méthode onReceive.

Pour plus d'informations (et un exemple) voir: http://olafurhelgason.blogspot.com/2012/12/threading-and-android-integration.html