Test Flaky Android Espresso - Snackbar

Question

1) Wszystkie testowane urządzenia/emulatory mają wyłączone animacje.

2) Mam @ BegletClass, który buduje mój obiekt Credentials.

3) Mam IntenServiceIdlingResource i EventBusIdlingResource, zarejestrowany w @ Przed rozpoczęciem.

4) Po kliknięciu przycisku logowania IntentService odpala się. W takim przypadku serwer (fałszywy serwer) zwraca błąd 500. Informacje te są przesyłane z powrotem do interfejsu użytkownika z IntentService za pośrednictwem EventBus greenrobota, a pasek Snackbar jest wyświetlany wraz z komunikatem o błędzie.

Oto kod do testu:

@Test 
public void a_userNamePasswordTest() throws Exception { 
    // email input 
    ViewInteraction userNameView = onView(withId(R.id.email)); 

    // verify it's on screen and enabled 
    userNameView.check(matches(isDisplayed())).check(matches(isEnabled())); 

    // set the username 
    userNameView.perform(scrollTo(), replaceText(credentials.username), closeSoftKeyboard()); 

    // password input 
    ViewInteraction passwordView = onView(withId(R.id.password)); 

    // verify it's on screen and enabled 
    passwordView.check(matches(isDisplayed())).check(matches(isEnabled())); 

    // set the password. 
    passwordView.perform(scrollTo(), replaceText(credentials.password), closeSoftKeyboard()); 

    // sign in button 
    ViewInteraction signInButton = onView(withId(R.id.email_sign_in_button)); 

    // verify the button 
    signInButton.check(matches(allOf(
      isDisplayed(), isEnabled(), withText("Sign In"), withContentDescription("Sign In") 
    ))); 

    // clickity click the button 
    signInButton.perform(scrollTo(), click()); 

    // verify the snackbar text 
    onView(withText(startsWith("Server Error: 500"))).check(matches(isDisplayed())); 

} 

To jest wyjątek I zazwyczaj:

SignInExceptionTest > a_userNamePasswordTest[Nexus_6P_API_23(AVD) - 6.0] FAILED android.support.test.espresso.NoMatchingViewException: No views in hierarchy found matching: with text: a string starting with "Server Error: 500"

Według mojego logowania, moje zasoby na biegu jałowym pracuje. Ale patrząc na znaczniki czasu dla dzienników, wyjątek ma miejsce około 5 sekund po tym, jak zasoby bezczynności zostały bezczynne.

Wygląda na to, że występuje opóźnienie między momentem braku zasobów a próbą wyszukania widoku.

Inne potencjalnie istotne szczegóły:

• minSdk: 20
• kompilacji & targetSdk 25
• buildTools: 25.0.2
• wsparcie Biblioteka: 25.1.1
• espresso rdzeń : 2.2.2
• wtyczka gradle 2.3.0-beta3

W jaki sposób mogę naprawić ten test, aby nie był łuszczący się, poza podnoszeniem czasu wyświetlania moich bufetów?

Answer 1

Espresso wymusza 5-sekundowe oczekiwanie, zanim IdlingResource stanie się aktywny, zanim zostanie ponownie sprawdzony na biegu jałowym.

Ma to 2 negatywne skutki w moim przypadku.

Po pierwsze, zwiększa czas działania testu. Dodatkowe 5 sekund (lub wielokrotność 5) w każdym teście może naprawdę się sumować.

Po drugie, ponieważ snackbar jest wyświetlany natychmiast i wyświetla się tylko przez około 3,5 sekundy, prawie za każdym razem, gdy czeka się na IdlingResource, snackbar zniknie, zanim Espresso zorientuje się, że zasób jest bezczynny, co utrudnia testować.

ConditionWatcher, opisane tutaj: https://medium.com/azimolabs/wait-for-it-idlingresource-and-conditionwatcher-602055f32356#.9rms52osh

i kod tutaj: https://github.com/AzimoLabs/ConditionWatcher

dostarcza rozwiązania dla obu tych zagadnień. Zamiast 5 sekund, domyślnie jest to 250 ms, a wartość tę można dostosować (setWatchInterval).