Nieaktywny zasób reprezentuje operację asynchroniczną, której wyniki mają wpływ kolejnych operacji w teście interfejsu. Rejestrując nieaktywne zasoby za pomocą Espresso, możesz uzyskać bardziej niezawodną weryfikację tych operacji asynchronicznych, gdy testowania aplikacji.
Określ, kiedy potrzebne są nieaktywne zasoby
Kawa espresso oferuje elegancki zestaw
synchronizacji danych. Ten
odnosi się jednak wyłącznie do operacji, które
wiadomości w MessageQueue
, takie jak podklasa
View
, który rysuje swoją zawartość na ekranie.
Ponieważ Espresso nie wie o żadnych innych operacjach asynchronicznych, w tym jeśli działa w wątku w tle, Espresso nie może gwarancjami w takich sytuacjach. Aby zapoznać się z długo trwających operacji, musisz zarejestrować każdą z nich jako bezczynny zasób.
Jeśli przy testowaniu wyników aplikacji nie używasz bezczynnych zasobów asynchronicznej, może być konieczne użycie jednej z stosowanie „złych rozwiązań tymczasowych, aby poprawić wyniki” niezawodność:
- Dodaję połączenia do:
Thread.sleep()
. Gdy sztuczne opóźnienia w testach, bo wydłużenie czasu testowania i może jej się zakończyć. Testy mogą nadal zakończyć się niepowodzeniem na wolniejszych urządzeniach. Poza tym opóźnienia te nie skalują się odpowiednio, ponieważ aplikacja może będą musieli przeprowadzać bardziej czasochłonne asynchroniczne prace w kolejnej wersji. - Implementowanie kodów ponownych prób, które używają pętli do wielokrotnego sprawdzania, czy aplikacja wykonuje działania asynchroniczne, dopóki nie nastąpi przekroczenie limitu czasu. Nawet jeśli określić maksymalną liczbę ponownych prób w testach, każde ponowne wykonanie zużywa zasobów systemowych, a zwłaszcza procesora.
- Używanie instancji
CountDownLatch
,która zezwól jednemu lub kilku wątkom na oczekiwanie na określoną liczbę operacji wykonanych w innym wątku. Te obiekty wymagają określenia limit czasu; W przeciwnym razie aplikacja może zostać zablokowana na stałe. Zatrzaski które niepotrzebnie komplikują kod i utrudniają jego obsługę.
Espresso pozwala wyeliminować te mniej niezawodne rozwiązania z testów i zamiast tego zarejestrować asynchroniczną pracę aplikacji jako bezczynne zasoby.
Częste zastosowania
Podczas wykonywania w testach operacji podobnych do poniższych rozważ użycie bezczynnego zasobu:
- Wczytywanie danych z internetu lub lokalnego źródła danych.
- nawiązywanie połączeń z bazami danych i wywołaniami zwrotnymi;
- Zarządzanie usługami za pomocą usługi systemowej lub instancji
IntentService
- Wykonywanie złożonej logiki biznesowej, np. przekształceń mapy bitowej.
Rejestracja nieaktywnych zasobów jest szczególnie ważna, gdy te operacje zaktualizować interfejs, który zostanie zweryfikowany przez testy.
Przykładowe implementacje bezczynnych zasobów
Na liście poniżej znajdziesz kilka przykładowych implementacji nieaktywnych zasobów które możesz zintegrować z aplikacją:
CountingIdlingResource
- Masz licznik aktywnych zadań. Gdy licznik ma wartość zero, powiązany element
zasób jest uznawany za bezczynny. Ta funkcja bardzo przypomina funkcję
Semaphore
W większości przypadków jest to wystarcza do zarządzania asynchroniczną pracą aplikacji podczas jej testowania. UriIdlingResource
- Podobne do
CountingIdlingResource
, ale dla określonego okresu przed zasób jest uznawany za bezczynny. Ten dodatkowy okres oczekiwania trwa kolejno żądań sieciowych, gdzie aplikacja z wątku może utworzyć nowy natychmiast po otrzymaniu odpowiedzi na poprzednie zgłoszenie. IdlingThreadPoolExecutor
- Niestandardowa implementacja
ThreadPoolExecutor
który śledzi łączną liczbę uruchomionych zadań w utworzonym wątku. basenów. Te zajęcia korzystają z funkcjiCountingIdlingResource
do aby utrzymać licznik aktywnych zadań. IdlingScheduledThreadPoolExecutor
- Niestandardowa implementacja
ScheduledThreadPoolExecutor
Zapewnia to samo funkcji i możliwości,IdlingThreadPoolExecutor
na zajęciach, ale może też śledzić zadania zaplanowane na przyszłość lub które mają być okresowo wykonywane. .
Utwórz własny bezczynny zasób
Ponieważ w testach aplikacji używasz bezczynnych zasobów, konieczne może być podanie niestandardowe zarządzanie zasobami lub logowanie. W takich przypadkach podane w poprzedniej sekcji mogą nie wystarczyć. W takim przypadku możesz rozszerz jedną z tych implementacji bezczynnych zasobów lub utwórz własną.
Jeśli wdrażasz własną funkcję bezczynności zasobów, zachowaj następujące najlepsze zwłaszcza pierwszej:
- Wywołuj przejścia w stan bezczynności poza sprawdzaniem bezczynności.
- Gdy aplikacja stanie się nieaktywna, zadzwoń do
onTransitionToIdle()
. poza wszelkimi implementacjamiisIdleNow()
Dzięki temu Espresso nie robi sekundy, niepotrzebnie sprawdza, czy bezczynny zasób jest bezczynny.
Poniższy fragment kodu ilustruje tę rekomendację:
Kotlin
fun isIdle() { // DON'T call callback.onTransitionToIdle() here! } fun backgroundWorkDone() { // Background work finished. callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle. // Don't do any post-processing work beyond this point. Espresso now // considers your app to be idle and moves on to the next test action. }
Java
public void isIdle() { // DON'T call callback.onTransitionToIdle() here! } public void backgroundWorkDone() { // Background work finished. callback.onTransitionToIdle() // Good. Tells Espresso that the app is idle. // Don't do any post-processing work beyond this point. Espresso now // considers your app to be idle and moves on to the next test action. }
- Zarejestruj nieaktywne zasoby, zanim będą potrzebne.
Korzyści z synchronizacji związane z brakiem zasobów mają zastosowanie tylko po pierwszym wywołaniu tego zasobu przez Espresso
isIdleNow()
.Poniższa lista zawiera kilka przykładów tej właściwości:
- Jeśli zarejestrujesz bezczynny zasób w metodzie opatrzonej adnotacją
@Before
, bezczynny zasób zacznie obowiązywać w pierwszym wierszu każdego testu. - Jeśli zarejestrujesz bezczynny zasób w teście, bezczynny zasób zostanie zastosowany podczas następnego działania opartego na Espresso. To zachowanie nadal zachodzi nawet wtedy, gdy następne działanie znajduje się w tym samym teście co stwierdzenie, że rejestruje bezczynny zasób.
- Jeśli zarejestrujesz bezczynny zasób w metodzie opatrzonej adnotacją
- Wyrejestruj nieaktywne zasoby, gdy przestaniesz ich używać.
Aby oszczędzać zasoby systemowe, jak najszybciej wyrejestruj nieaktywne zasoby bo nie są już potrzebne. Jeśli na przykład zarejestrujesz bezczynny zasób w metodzie z adnotacjami
@Before
, najlepiej wyrejestrować ten zasób w odpowiedniej metody oznaczonej adnotacją@After
.- Użyj nieaktywnego rejestru, aby zarejestrować i wyrejestrować nieaktywne zasoby.
Korzystając z tego kontenera dla nieaktywnych zasobów aplikacji, możesz zarejestrować wyrejestrowuj bezczynne zasoby wielokrotnie w razie potrzeby i nadal obserwuj spójne zachowanie użytkownika.
- Utrzymuj prosty stan aplikacji w obrębie bezczynnych zasobów.
Na przykład zaimplementowane i rejestrowane bezczynne zasoby nie powinny zawierają odwołania do obiektów
View
.
Rejestrowanie bezczynnych zasobów
Espresso udostępnia klasę kontenera, w której można umieścić brak aktywności aplikacji
i zasobami Google Cloud. Te zajęcia, zwane
IdlingRegistry
to
samodzielnym artefaktem, który minimalizuje obciążenie aplikacji. Klasa
pozwala też na wykonanie
tych czynności w celu poprawy
łatwość utrzymania:
- Utwórz odwołanie do zasobu
IdlingRegistry
zamiast bezczynnych zasobów w testach aplikacji. - Zachowaj różnice w zbieraniu nieaktywnych zasobów, których używasz do każdego wariantu kompilacji.
- Zdefiniuj bezczynne zasoby w usługach aplikacji, a nie w interfejsie które odwołują się do tych usług.
Zintegruj z aplikacją bezczynne zasoby
Chociaż bezczynne zasoby można dodać do aplikacji na kilka różnych sposobów: i zadba o otoczenie aplikacji, a jednocześnie pozwala możesz określić konkretną operację reprezentowaną przez dany bezczynny zasób.
Zalecane działania
Zdecydowanie zalecamy przy dodawaniu nieaktywnych zasobów do aplikacji logikę bezczynności zasobów w samej aplikacji i wykonywanie wyłącznie rejestracji podczas wyrejestrowania.
Chociaż występuje nietypowa sytuacja, w której użytkownicy korzystają z interfejsu tylko do testów, kodu produkcyjnego, stosując się do tej metody, możesz opakować bezczynne zasoby wokół który już masz, z zachowaniem rozmiaru pliku APK i liczby metod.
Alternatywne sposoby
Jeśli nie chcesz korzystać z logiki bezczynności zasobów w środowisku produkcyjnym aplikacji jest kilka innych skutecznych strategii integracji:
- Możesz tworzyć warianty kompilacji, takie jak wersja Gradle’a produkt smaki i używaj bezczynnych zasobów tylko w kompilacji do debugowania aplikacji.
- Użyj platformy wstrzykiwania zależności, takiej jak Dagger, aby wstrzyknąć bezczynność aplikacji graf zależności zasobów. Jeśli używasz Daggera 2, samo wstrzykiwanie powinno pochodzić z podkomponentu.
Zaimplementuj bezczynny zasób w testach aplikacji i udostępnij część implementacji aplikacji, którą trzeba zsynchronizować w testów.
Uwaga: chociaż ta decyzja dotycząca projektu wydaje się tworzy niezależne odniesienie do bezczynnych zasobów, ale także można stosować w nie tylko najprostszych aplikacjach.
Dodatkowe materiały
Więcej informacji o używaniu Espresso w testach na Androidzie znajdziesz w poniższe zasoby.
Próbki
- IdlingResourceSample: Synchronizacja z zadaniami w tle.