Istniejące testy Androida UI przestały działać po przejściu na AndroidaJUnitRunner

Question

Mamy kilka testów interfejsu użytkownika dotyczących naszej funkcjonalności aparatu, a po przejściu z InstrumentationTestRunner na AndroidJUnitRunner w ramach naszego przeniesienia do Espresso/JUnit4, nie możemy już dłużej działać istniejące testy wiarygodny ze względu na częste RuntimeException kiedy nazywamy getActivity():

java.lang.RuntimeException: Could not launch intent Intent { flg=0x14000000 cmp=com.cookbrite.dev/com.cookbrite.ui.ReceiptCaptureActivity (has extras) } within 45 seconds. Perhaps the main thread has not gone idle within a reasonable amount of time? There could be an animation or something constantly repainting the screen. Or the activity is doing network calls on creation? See the threaddump logs. For your reference the last time the event queue was idle before your activity launch request was 1434471981236 and now the last time the queue went idle was: 1434471981236. If these numbers are the same your activity might be hogging the event queue. 
at android.support.test.runner.MonitoringInstrumentation.startActivitySync(MonitoringInstrumentation.java:315) 
at android.test.InstrumentationTestCase.launchActivityWithIntent(InstrumentationTestCase.java:119) 
at android.test.ActivityInstrumentationTestCase2.getActivity(ActivityInstrumentationTestCase2.java:106) 
at com.cookbrite.step2_functional.ui.receipt.ReceiptCaptureTest.getActivity(ReceiptCaptureTest.java:43) 

Dla lepszej czytelności, to jest komunikat o błędzie na RuntimeException jako cytat:

nie można uruchomić zamiaru Intent {FLG = 0x14000000 cmp = com.cookbrite.dev/com.cookbrite.ui.ReceiptCaptureActivity (ma dodatki)} w ciągu 45 sekund. Być może główny wątek nie został bezczynny w rozsądnym czasie? Może być animacja lub coś, co ciągle zmienia wygląd ekranu. Lub aktywność wykonuje połączeń sieciowych podczas tworzenia? Zobacz dzienniki wątków. Dla Twojej informacji Ostatni raz kolejka zdarzeń była bezczynna przed uruchomieniem działania. żądanie to było 1434471981236, a teraz, gdy ostatnio kolejka była bezczynna, było: 1434471981236. Jeśli te liczby są takie same, Twoja aktywność może przerwać kolejkę zdarzeń.

Nasze obecne testy wykorzystują Robotium. Próba napisania tego samego testu przy użyciu Espresso spowodowała podobny błąd, co prawdopodobnie wynika z ciągłego aktualizowania interfejsu użytkownika przez interfejs aparatu. Jednak nawet z podglądem ustawionym na INVISIBLE, nadal napotykamy ten problem z Espresso.

Wszelkie pomysły/wskazówki dotyczące rozwiązania problemu (inne niż powrót do wersji InstrumentationTestRunner)?

Answer 1

W końcu możemy zmienić UI opóźnić uruchomienie podglądu kamery tak MonitoringInstrumentation nie denerwować ze wszystkimi aktualizacji UI. Ponadto, zarówno aktualizacje SurfaceView i TextureView po aktualizacji są aktualizowane natychmiast po podłączeniu kamery, nawet w stanie INVISIBLE lub GONE. To powoduje, że MonitoringInstrumentation poddaje się w naszym przypadku.

Jeśli masz test, który rozpoczyna się od ciągłej aktualizacji interfejsu użytkownika, możesz rozważyć wstrzymanie działania do czasu zakończenia startActivitySync(), a otrzymasz niezerowy wynik z getActivity().

Answer 2

Wyjście błędu wskazuje, że klasa testowa rozszerza się o ActivityInstrumentationTestCase2. Nie jestem pewien, czy przeniesienie się do nowego ActivityTestRule będzie miało znaczenie w twoim przypadku, ale warto sprawdzić to szybko. Wyrażając to w odpowiedzi zamiast komentarza, aby zawierać przykładowy kod:

@RunWith(AndroidJUnit4.class) 
public class ReceiptCaptureTestNew { 
    private ReceiptCaptureActivity mReceiptCaptureActivity; 

    @Rule 
    public ActivityTestRule<mReceiptCaptureActivity> mActivityRule = 
      new ActivityTestRule<>(mReceiptCaptureActivity.class); 

    @Before 
    public void setUp() throws Exception { 
     mReceiptCaptureActivity = mActivityRule.getActivity(); 
    } 

    @After 
    public void tearDown() throws Exception { 
     // Call finish() on all activities in @After to avoid exceptions in 
     // later calls to getActivity() in subsequent tests 
     mReceiptCaptureActivity.finish(); 
    } 

    @Test 
    public void testPreconditions() { 
     assertNotNull(mReceiptCaptureActivity); 
     assertThat(mReceiptCaptureActivity.hasWindowFocus(), is(true)); 
    } 
}