Во втором тесте getActivity () никогда не возвращается - PullRequest
6 голосов
/ 15 января 2012

У меня есть пара простых тестов, например assertNotNull(mActivity); (я читаю MDTorres «Руководство по тестированию приложений Android»).Тестируемая активность работает нормально.Каждый тест проходит нормально.Но если я запускаю несколько тестов одновременно, второй тест getActivity() никогда не возвращается.Нет ошибок в logcat (последняя строка "Starting Intent ..."), нет ничего.Отладка тоже мало помогает, если я захожу на getActivity(), он жалуется, что нет доступного исходного кода.
Другой тестовый проект - ActivityTesting от Google работает нормально даже с несколькими тестами, поэтому Eclipse настроен правильно.* Кто-нибудь когда-нибудь сталкивался с чем-то подобным?

Ответы [ 2 ]

8 голосов
/ 15 января 2012

Я заново создал тестовый проект (например, «чистая комната»), и он заработал.Затем я сравнил два проекта и нашел виновника.Это был пустой демонтаж:

protected void tearDown() throws Exception {
}

Если я удаляю его, все тесты запускаются зелеными.Если я вставлю его обратно, второй тест зависнет.Теперь я хотел бы прочитать объяснение и быть готовым пометить его как ответ.

Редактировать: Я должен вызывать super.tearDown() в конце метода tearDown.Извините, что беспокою всех.

1 голос
/ 26 июня 2015

Я использовал ActivityInstrumentationTestCase2 для тестирования Activity с использованием ExoPlayer и корректной очистки ресурсов.Поскольку очистка и финальные проверки одинаковы для всех тестов, я подумал, что tearDown () - хорошее место для их реализации.Все тесты выполняются отдельно без каких-либо проблем, но когда я запускаю несколько тестов, иногда getActivity () не возвращается.Мой tearDown () реализовал различные вещи:

  • проверка состояния активности (различные вызовы assert ())
  • проверка состояния игрока (различные вызовы assert ())
  • очищать ресурсы игрока вручную (вызывая close () и release ())
  • setActivity (null) (это вызвало проблему)
  • super.tearDown ()

Я попробовал все предложенные обходные пути, такие как переопределение getActivity () и использование других методов инструментария для создания и очистки действия.Эти методы не помогли.

И многие отладки показали, что при вышеописанном сценарии onDestory () активности предыдущего теста может перекрываться с onCreate () активности следующего теста.Таким образом, в журналах показывались события жизненного цикла в следующем порядке:

test1.getActivity();
test1.tearDown() called;
test1.tearDown() over;
test2.getActivity()
test2.onCreate();
test1.onStop(); --> why is this late?
test1.onDestroy(); --> why is this late?
test2.tearDown() called;
test2.tearDown() over;
test3.getActiviy() --> this should call test3.onCreate, but did not and never returned.

Это происходит, даже когда контрольные примеры реализованы в отдельных классах / файлах ActivityInstrumentationTestCase2.И в первый раз это перекрытие еще не вызывает проблем, поэтому 2 теста всегда в порядке, но выполнение 3 тестов в любом порядке, которое приводит к этому перекрытию, приводит к тому, что третий вызов getActivity () никогда не вернется.

Iпробовал все, например, вызов onPause () + onStop () + onDestroy () вручную с использованием инструментария, введение действительно длинных периодов сна между тестами, принудительная очистка активности instrumentationTestCase, переупорядочивание проверок моего tearDown, но ничего не помогло.Наконец, я случайно удалил setActivity (null) перед своими проверками, и события жизненного цикла были правильно упорядочены:

test1.tearDown() called;
test1.onStop();
test1.onDestroy();
test1.tearDown() over;
test2.getActivity()
test2.onCreate();
...

Итак, что действительно изменило ситуацию в моем случае: не вызывайте ActivityTestCase.setActivity ().Это заставляет super.tearDown () не вызывать события жизненного цикла напрямую, очистка произойдет позже и вызовет проблемы.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...