Почему нет тестового инструментария для BroadcastReceiver? - PullRequest
11 голосов
/ 02 ноября 2010

Может быть, я что-то упустил. Я хочу написать контрольные примеры для BroadcastReceiver; в частности, он предназначен для получения события BOOT_COMPLETED и установки будильника для другого получателя для последующей обработки; Похоже, он не настраивается должным образом, но дело в том, что у меня нет очевидного способа проверить это. Я не могу подключить отладчик и ждать BOOT_COMPLETED, и я не могу отправить поддельную трансляцию BOOT_COMPLETED.

Почему существуют классы инструментария для Activity, Service и Provider, но не для BroadcastReceiver? Любой совет для проверки этого?

Ответы [ 2 ]

18 голосов
/ 03 марта 2011

В жизненном цикле BroadcastReceiver нет ничего волшебного. Достаточно проверить это с помощью AndroidTestCase. В тестовом примере создайте экземпляр вашего BroadcastReceiver, создайте любое намерение, которое вы хотите отправить, и вызовите onReceive, используя контекст, доступный в AndroidTestCase, или какой-то фиктивный контекст.

* 1003 Е.Г. *

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
  }
}
7 голосов
/ 05 декабря 2012

В большинстве случаев я полностью согласен с https://stackoverflow.com/a/5181010/527016

Однако существуют случаи, когда расширение AndroidTestCase не подходит (и может вызывать неожиданности). В частности, если вы проводите более сложное интеграционное тестирование и хотите проверить BroadcastReceiver с фактическим Intent, отправленным системой. Основная причина в том, что метод onReceive в приемнике вещания выполняется в главном потоке приложения, а тесты в AndroidTestCase выполняются в другом потоке. Это может вызвать связанные с тестированием проблемы с потоками в коде, который не предназначен для работы в нескольких потоках.

Решение этой проблемы состоит в том, чтобы вместо этого сделать подкласс теста с InstrumentationTestCase и использовать аннотацию @UiThreadTest, чтобы тесты выполнялись в том же потоке, что и метод onReceive.

Для получения дополнительной информации (и примера) см .: http://olafurhelgason.blogspot.com/2012/12/threading-and-android-integration.html

...