Dans cet article, vous allez apprendre à utiliser l'API de test waitUntil dans Compose pour attendre que certaines conditions soient remplies. Dans certains cas, il s'agit d'une bonne alternative à l'utilisation des ressources d'inactivité.

[Mise à jour de 2023] En bref : utilisez les nouvelles API waitUntil pour la synchronisation dans les tests Compose (v1.4.0 et versions ultérieures).

Qu'est-ce que la synchronisation ?

Une façon de catégoriser les tests est de les classer par portée. Les petits tests, ou tests unitaires, se concentrent sur de petites parties de votre application, tandis que les grands tests, ou tests de bout en bout, couvrent une grande partie de votre application. Vous pouvez en savoir plus sur ces types de tests et d'autres dans la documentation sur les tests, qui a été récemment mise à jour.

Appuyez sur Entrée ou cliquez pour afficher l'image en taille réelle

La synchronisation est le mécanisme qui permet au test de savoir quand exécuter la prochaine opération. Plus le bloc de code que vous choisissez de valider est important, plus il est difficile de le synchroniser avec le test. Dans les tests unitaires, il est facile de contrôler entièrement l'exécution du code à vérifier. Toutefois, à mesure que nous élargissons le champ d'application pour inclure davantage de classes, de modules et de couches, il devient difficile pour le framework de test de savoir si l'application est en cours d'opération ou non.

Appuyez sur Entrée ou cliquez pour afficher l'image en taille réelle

androidx.test et, par extension, Compose Test, utilisent quelques astuces en arrière-plan pour que vous n'ayez pas trop à vous en soucier. Par exemple, si le thread principal est occupé, le test s'interrompt jusqu'à ce qu'il puisse exécuter la ligne suivante.

Toutefois, elles ne peuvent pas tout savoir. Par exemple, si vous chargez des données dans un thread d'arrière-plan, le framework de test peut exécuter l'opération suivante trop tôt, ce qui fait échouer votre test. Le pire scénario est celui où cela ne se produit que dans un faible pourcentage de cas, ce qui rend le test instable.

Option 1 : Ressources asynchrones

Les ressources d'inactivité sont une fonctionnalité Espresso qui vous permet, en tant que développeur, de déterminer quand l'application est occupée. Vous pouvez les utiliser de deux manières :

1. en les installant dans le framework ou la bibliothèque qui effectue un travail que le test ne peut pas voir.

RxIdler, qui encapsule un planificateur RxJava, en est un bon exemple. Il s'agit de la méthode recommandée pour enregistrer les ressources inactives, car elle vous permet de séparer clairement la configuration du test du code de test.

2. Modifiez votre code en cours de test pour exposer explicitement des informations indiquant si votre application est occupée ou non.

Par exemple, vous pouvez modifier votre dépôt (ou un test double) pour indiquer qu'il est occupé lors du chargement des données à partir d'une source de données :

Ce n'est pas idéal, car vous polluez votre code de production ou créez des doubles de test complexes. De plus, il est parfois difficile de les installer. Par exemple, comment utiliseriez-vous les ressources d'inactivité dans un flux Kotlin ? Quelle est la mise à jour finale ?

Au lieu de cela, nous pouvons attendre que les choses se produisent.

Option 2 : Attendre les choses… de la mauvaise manière

Le chargement des données est généralement rapide, surtout lorsque vous utilisez de fausses données. Alors, pourquoi perdre du temps avec des ressources inactives alors que vous pouvez simplement faire dormir le test pendant quelques secondes ?

Ce test s'exécutera plus lentement que nécessaire ou échouera. Lorsque vous avez des centaines ou des milliers de tests d'UI, vous souhaitez qu'ils soient aussi rapides que possible.

De plus, il arrive que des émulateurs ou des appareils se comportent mal et saccadent, ce qui fait que cette opération prend un peu plus de temps que ces 2 000 ms, ce qui interrompt votre compilation. Lorsque vous avez des centaines de tests, cela devient un problème majeur.

Option 3 : Attendre les choses de la bonne manière !

Si vous ne souhaitez pas modifier votre code en cours de test pour indiquer quand il est occupé, vous pouvez également attendre qu'une certaine condition soit remplie, au lieu d'attendre une durée arbitraire.

Dans Compose, vous pouvez utiliser la fonction waitUntil, qui prend une autre fonction produisant un booléen.

Mise à jour du 22/03/2023 : à partir de Compose 1.4.0, nous avons ajouté un nouvel ensemble d'API waitUntil :

[Avant la version 1.4.0 : utilisez ces assistants : waitUntilExists, waitUntilNodeCount]

… et utilisez-les comme suit :

N'utilisez ces API que lorsque vous devez synchroniser votre test avec l'UI. La synchronisation sur chaque instruction de test pollue inutilement le code de test, ce qui rend la maintenance plus difficile.

Quand l'utiliser ? Il est particulièrement utile pour charger des données à partir d'un observable (avec LiveData, Kotlin Flow ou RxJava). Lorsque votre UI doit recevoir plusieurs mises à jour avant d'être considérée comme inactive, vous pouvez simplifier la synchronisation à l'aide de waitUntil.

Par exemple, lorsque vous collectez un flux à partir d'une vue :

Vous émettez plusieurs éléments :

Si repository met un temps indéterminé à renvoyer le premier résultat, le framework de test pensera que "Loading" (Chargement) est l'état inactif (la valeur initiale attribuée dans collectAsState) et passera à l'instruction suivante.

Vous pouvez donc rendre le test beaucoup plus fiable en vous assurant que l'UI n'affiche pas l'indicateur de chargement :

Bon… attendez… test !

Licence des extraits de code :

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