Czy można wyłączyć toasty lub poczekać, aż toast zniknie podczas testowania?

Question

Testuję aplikację z Espresso. Mam jedno pytanie, czy można poczekać, aż nie pojawi się toast. Mam dużo różnych tostów w mojej aplikacji, ale podczas testowania mam z nimi problemy, ponieważ o ile mogę się domyślić, skupiłem się na toście i otrzymuję zupełnie inną hierarchię widoków, co widzę w dziennikach błędów.
Moje pytanie jest więc możliwe, aby ukryć wszystkie (systemowe z dostępem do roota) lub po prostu poczekać, aż na ekranie pojawią się jakieś grzanki lub, jeśli możliwe, ręcznie ustawić hierarchię widoku aktywności.
Byłbym wdzięczny za pomoc w rozwiązaniu tego problemu.
Dziękuję.

P.S. Wyłączenie toastu bezpośrednio w mojej aplikacji nie jest opcją, ponieważ wprowadza do aplikacji dodatkową logikę, która jest wymagana tylko podczas testowania.

Answer 1

Możesz pozwolić Espresso poczekać, aż znikną wszystkie grzanki za pomocą niestandardowego zasobu na biegu jałowym .

Tutaj używam CountingIdlingResource, który jest zasobem bezczynności zarządzającym licznikiem: gdy licznik zmienia się z niezerowego na zero, powiadamia o przełączeniu zwrotnym.

Here jest kompletnym przykładem; Kluczowe punkty wykonaj:

public final class ToastManager { 
    private static final CountingIdlingResource idlingResource = new CountingIdlingResource("toast"); 
    private static final View.OnAttachStateChangeListener listener = new View.OnAttachStateChangeListener() { 
     @Override 
     public void onViewAttachedToWindow(final View v) { 
      idlingResource.increment(); 
     } 

     @Override 
     public void onViewDetachedFromWindow(final View v) { 
      idlingResource.decrement(); 
     } 
    }; 

    private ToastManager() { } 

    public static Toast makeText(final Context context, final CharSequence text, final int duration) { 
     Toast t = Toast.makeText(context, text, duration); 
     t.getView().addOnAttachStateChangeListener(listener); 
     return t; 
    } 

    // For testing 
    public static IdlingResource getIdlingResource() { 
     return idlingResource; 
    } 
} 

Jak pokazują tosty:

ToastManager.makeText(this, "Third", Toast.LENGTH_SHORT).show(); 

Jak Ustawienie/rozdarcie-down test:

@Before 
public void setUp() throws Exception { 
    super.setUp(); 
    injectInstrumentation(InstrumentationRegistry.getInstrumentation()); 
    Espresso.registerIdlingResources(ToastManager.getIdlingResource()); 
    getActivity(); 
} 

@After 
public void tearDown() throws Exception { 
    super.tearDown(); 
    Espresso.unregisterIdlingResources(ToastManager.getIdlingResource()); 
} 

Answer 2

nie znalazłem każdy doskonały rozwiązanie tego, ale najlepiej jest uczynić zmienną składową mToast widoczną do testowania i użyć jej do anulowania aktywnego toastu w @After, podobnie jak to:

Wykazując tost (kod produkcyjny na aktywność badanego)

@VisibleForTesting(otherwise = VisibleForTesting.PRIVATE) 
Toast mToast; 

private void showToast(final String text) { 
    mToast = Toast.makeText(this, text, Toast.LENGTH_LONG); 
    mToast.show(); 
} 

kod testowy (w tym samym opakowaniu co kod badanego)

@After 
    public void tearDown() { 
     // Remove any toast message that is still shown: 
     Toast toast = mActivityRule.getActivity().mToast; 
     if (toast != null) { 
      toast.cancel(); 
     } 
    } 

to będzie Wymagaj niewielkiej zmiany kodu produkcyjnego, ale użycie @VisibleForTesting w najnowszej wersji Androida Studio spowoduje błąd, jeśli użyjesz zmiennej członka w innym miejscu.