Alternativen zu Idling Resources in Compose-Tests: Die waitUntil APIs (aktualisiert)

In diesem Artikel erfahren Sie, wie Sie die waitUntil-Test-API in Compose verwenden, um zu warten, bis bestimmte Bedingungen erfüllt sind. In einigen Situationen ist das eine gute Alternative zu Idling Resources.

[Aktualisierung 2023] Kurze Zusammenfassung: Verwenden Sie die neuen waitUntil APIs, um in Compose-Tests zu synchronisieren (Version 1.4.0 oder höher).

Was ist Synchronisierung?

Tests können unter anderem nach ihrem Umfang kategorisiert werden. Kleine Tests oder Unit-Tests konzentrieren sich auf kleine Teile Ihrer App, während große Tests oder End-to-End-Tests einen großen Teil Ihrer App abdecken. Weitere Informationen zu diesen und anderen Testtypen finden Sie in der aktualisierten Testdokumentation.

Drücken Sie die Eingabetaste oder klicken Sie, um das Bild in voller Größe anzusehen.

Synchronisierung ist der Mechanismus, mit dem der Test weiß, wann die nächste Operation ausgeführt werden muss. Je größer der Codeabschnitt ist, den Sie überprüfen möchten, desto schwieriger ist die Synchronisierung mit dem Test. In Unit-Tests haben Sie die volle Kontrolle über die Ausführung des zu überprüfenden Codes. Wenn Sie den Umfang jedoch auf weitere Klassen, Module und Ebenen ausweiten, wird es für das Test-Framework schwierig zu erkennen, ob die App gerade eine Operation ausführt oder nicht.

Drücken Sie die Eingabetaste oder klicken Sie, um das Bild in voller Größe anzusehen.

androidx.test und damit auch Compose Test verwenden einige Tricks im Hintergrund, sodass Sie sich nicht zu viele Gedanken darüber machen müssen. Wenn beispielsweise der Hauptthread ausgelastet ist, wird der Test angehalten, bis die nächste Zeile ausgeführt werden kann.

Allerdings können sie nicht alles wissen. Wenn Sie beispielsweise Daten in einem Hintergrundthread laden, führt das Test-Framework die nächste Operation möglicherweise zu früh aus, wodurch der Test fehlschlägt. Am schlimmsten ist es, wenn das nur in einem kleinen Prozentsatz der Fälle passiert, wodurch der Test unzuverlässig wird.

Option 1: Idling Resources

Idling Resources sind eine Espresso-Funktion, mit der Sie als Entwickler entscheiden können, wann die App ausgelastet ist. Sie haben zwei Möglichkeiten, sie zu verwenden:

1. Sie können sie in dem Framework oder der Bibliothek installieren, die Arbeit verrichtet, die der Test nicht sehen kann.

Ein gutes Beispiel dafür ist RxIdler, das einen RxJava-Scheduler umschließt. Das ist die bevorzugte Methode zum Registrieren von Idling Resources, da Sie die Testeinrichtung sauber vom Testcode trennen können.

2. Sie können den zu testenden Code so ändern, dass Informationen darüber, ob Ihre App ausgelastet ist oder nicht, explizit verfügbar gemacht werden.

Sie könnten beispielsweise Ihr Repository (oder ein Test-Double) so ändern, dass es angibt, dass es ausgelastet ist, während Daten aus einer Datenquelle geladen werden:

Das ist nicht ideal, da Sie Ihren Produktionscode verunreinigen oder komplizierte Test-Doubles erstellen. Außerdem gibt es einige Situationen, in denen sie schwer zu installieren sind. Wie würden Sie beispielsweise Idling Resources in einem Kotlin Flow verwenden? Welches Update ist das endgültige ?

Stattdessen können wir warten, bis bestimmte Dinge passieren.

Option 2: Auf Dinge warten… auf die falsche Weise

Das Laden von Daten ist in der Regel schnell, insbesondere bei Verwendung von Testdaten. Warum also Zeit mit Idling Resources verschwenden, wenn Sie den Test einfach ein paar Sekunden lang anhalten können?

Dieser Test wird entweder langsamer als nötig ausgeführt oder schlägt fehl. Wenn Sie Hunderte oder Tausende von UI-Tests haben, sollten diese so schnell wie möglich ausgeführt werden.

Außerdem verhalten sich Emulatoren oder Geräte manchmal nicht richtig und ruckeln, sodass die Operation etwas länger als 2.000 ms dauert und Ihr Build fehlschlägt. Wenn Sie Hunderte von Tests haben, wird das zu einem großen Problem.

Option 3: Auf Dinge warten… auf die richtige Weise

Wenn Sie den zu testenden Code nicht ändern möchten, um zu zeigen, wann er ausgelastet ist, können Sie stattdessen warten, bis eine bestimmte Bedingung erfüllt ist, anstatt eine beliebige Zeit zu warten.

In Compose können Sie die Funktion „waitUntil“ verwenden, die eine andere Funktion akzeptiert, die einen booleschen Wert zurückgibt.

Aktualisierung vom 22.03.2023: Ab Compose 1.4.0 haben wir eine neue Reihe von waitUntil APIs hinzugefügt:

[Vor 1.4.0: Verwenden Sie diese Hilfsfunktionen: waitUntilExists, waitUntilNodeCount]

… und verwenden Sie sie so:

Verwenden Sie diese APIs nur, wenn Sie Ihren Test mit der UI synchronisieren müssen. Wenn Sie bei jeder Testanweisung synchronisieren, wird der Testcode unnötig verunreinigt und die Wartung erschwert.

Wann sollten Sie sie also verwenden? Ein guter Anwendungsfall ist das Laden von Daten aus einem Observable (mit LiveData, Kotlin Flow oder RxJava). Wenn Ihre UI mehrere Aktualisierungen erhalten muss, bevor sie als inaktiv gilt, können Sie die Synchronisierung mit waitUntil vereinfachen.

Beispiel: Wenn Sie einen Flow aus einer Ansicht erfassen:

Und Sie mehrere Elemente ausgeben:

Wenn es eine unbestimmte Zeit dauert, bis repository das erste Ergebnis zurückgibt, geht das Test-Framework davon aus, dass „Loading“ der inaktive Status ist (der Anfangswert, der in collectAsState zugewiesen wurde), und fährt mit der nächsten Anweisung fort.

Sie können den Test also viel zuverlässiger machen, wenn Sie dafür sorgen, dass der Ladeindikator nicht in der UI angezeigt wird:

Viel Spaß beim… Warten… Testen!

Lizenz für Code-Snippets:

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