Z tego artykułu dowiesz się, jak używać interfejsu waitUntil test API w Compose, aby czekać na spełnienie określonych warunków. W niektórych sytuacjach jest to dobra alternatywa dla korzystania z zasobów bezczynnych.

[Aktualizacja z 2023 r.] Podsumowanie: w testach Compose (wersja 1.4.0 lub nowsza) używaj nowych interfejsów API waitUntil do synchronizacji.

Co to jest synchronizacja?

Jednym ze sposobów kategoryzowania testów jest ich zakres. Małe testy, czyli testy jednostkowe, koncentrują się na małych fragmentach aplikacji, a duże testy, czyli testy kompleksowe, obejmują dużą część aplikacji. Więcej informacji o tych i innych rodzajach testów znajdziesz w zaktualizowanej dokumentacji testów.

Naciśnij Enter lub kliknij, aby wyświetlić obraz w pełnym rozmiarze

Synchronizacja to mechanizm, który informuje test o tym, kiedy należy uruchomić następną operację. Im większy fragment kodu wybierzesz do weryfikacji, tym trudniej będzie go zsynchronizować z testem. W testach jednostkowych łatwo jest mieć pełną kontrolę nad wykonywaniem kodu, który ma zostać zweryfikowany. Jednak w miarę rozszerzania zakresu o kolejne klasy, moduły i warstwy platforma testowa ma coraz większe trudności z określeniem, czy aplikacja jest w trakcie wykonywania operacji.

Naciśnij Enter lub kliknij, aby wyświetlić obraz w pełnym rozmiarze

androidx.test, a co za tym idzie Compose Test, używają pewnych sztuczek, dzięki czemu nie musisz się tym zbytnio przejmować. Jeśli na przykład wątek główny jest zajęty, test zostanie wstrzymany do momentu, gdy będzie można wykonać następny wiersz.

Nie mogą jednak wiedzieć wszystkiego. Jeśli na przykład wczytujesz dane w wątku w tle, platforma testowa może zbyt szybko wykonać następną operację, co spowoduje niepowodzenie testu. Najgorsza sytuacja to taka, gdy zdarza się to tylko w niewielkim odsetku przypadków, co sprawia, że test jest niestabilny.

Opcja 1. Nieaktywne zasoby

Zasoby bezczynne to funkcja Espresso, która pozwala deweloperowi określić, kiedy aplikacja jest zajęta. Możesz ich używać na 2 sposoby:

1. instalowanie ich w frameworku lub bibliotece, które wykonują pracę niewidoczną dla testu.

Dobrym przykładem jest RxIdler, który opakowuje harmonogram RxJava. Jest to preferowany sposób rejestrowania zasobów bezczynnych, ponieważ pozwala zachować wyraźny podział między konfiguracją testu a kodem testu.

2. Zmodyfikowanie testowanego kodu, aby wyraźnie udostępniać informacje o tym, czy aplikacja jest zajęta.

Możesz na przykład zmodyfikować repozytorium (lub testowy obiekt zastępczy), aby wskazywał, że jest zajęty podczas wczytywania danych ze źródła danych:

Nie jest to idealne rozwiązanie, ponieważ zanieczyszcza kod produkcyjny lub tworzy skomplikowane obiekty testowe, a w niektórych sytuacjach trudno je zainstalować. Na przykład jak używać Idling Resources w przepływie Kotlin? Która aktualizacja jest ostatnią?

Zamiast tego możemy poczekać.

Opcja 2. Czekanie na coś… w niewłaściwy sposób

Wczytywanie danych jest zwykle szybkie, zwłaszcza w przypadku danych testowych, więc po co marnować czas na bezczynne zasoby, skoro można po prostu uśpić test na kilka sekund?

Ten test będzie działać wolniej niż powinien lub zakończy się niepowodzeniem. Jeśli masz setki lub tysiące testów interfejsu, chcesz, aby były one jak najszybsze.

Czasami emulatory lub urządzenia działają nieprawidłowo i zacinają się, przez co operacja trwa nieco dłużej niż 2000 ms, co powoduje przerwanie kompilacji. Gdy masz setki testów, staje się to poważnym problemem.

Opcja 3. Czekanie we właściwy sposób

Jeśli nie chcesz modyfikować testowanego kodu, aby ujawniać, kiedy jest zajęty, możesz zamiast czekać przez określony czas poczekać, aż zostanie spełniony określony warunek.

W Compose możesz użyć funkcji waitUntil, która przyjmuje inną funkcję zwracającą wartość logiczną.

Aktualizacja z 22 marca 2023 r.: od wersji Compose 1.4.0 dodaliśmy nowy zestaw interfejsów API waitUntil:

[Przed wersją 1.4.0: użyj tych funkcji pomocniczych: waitUntilExists, waitUntilNodeCount]

…i używaj ich w ten sposób:

Używaj tych interfejsów API tylko wtedy, gdy musisz zsynchronizować test z interfejsem. Synchronizowanie każdego stwierdzenia testu niepotrzebnie zaśmieca kod testu, co utrudnia jego utrzymanie.

Kiedy więc należy go używać? Dobrym przykładem zastosowania jest wczytywanie danych z obiektu obserwowalnego (za pomocą LiveData, Kotlin Flow lub RxJava). Jeśli interfejs użytkownika musi otrzymać wiele aktualizacji, zanim zostanie uznany za nieaktywny, możesz uprościć synchronizację za pomocą waitUntil.

Na przykład gdy zbierasz Flow z widoku:

i emitujesz do niego wiele elementów:

Jeśli repository potrzebuje nieokreślonego czasu, aby zwrócić pierwszy wynik, platforma testowa uzna „Loading” za stan bezczynności (wartość początkowa przypisana w collectAsState) i przejdzie do następnej instrukcji.

Możesz znacznie zwiększyć wiarygodność testu, jeśli upewnisz się, że interfejs nie wyświetla wskaźnika ładowania:

Miłego… poczekaj… testowania!

Licencja na fragmenty kodu:

Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0