Lorsque vous concevez une stratégie de test pour un élément ou un système, aspects des tests associés:
- Portée: quelle partie du code le test touche-t-il ? Les tests peuvent vérifier un seul l'application entière, ou quelque part entre les deux. La le champ d'application testé est en cours de test et le désigne généralement par le terme Test, mais aussi System Under Test (Système en cours de test) ou Unit Under Test (Unité en cours de test).
- Vitesse: à quelle vitesse le test s'exécute-t-il ? La vitesse des tests peut varier en millisecondes à plusieurs minutes.
- Fidélité: comment le "monde réel" le test ? Par exemple, si une partie du code que vous testez doit effectuer une requête réseau, le code de test envoie-t-il à cette demande réseau, ou fausse-t-il le résultat ? Si le test parle réellement avec le réseau, cela signifie qu'il est plus fidèle. En contrepartie, le test pourrait durer plus longtemps, provoquer des erreurs en cas de panne du réseau ou pourrait être coûteuse à utiliser.
Consultez la section Éléments à tester pour commencer à définir votre stratégie de test.
Isolation et dépendances
Lorsque vous testez un élément ou un système d'éléments, vous le faites isolement. Pour Par exemple, pour tester un ViewModel, il n'est pas nécessaire de démarrer un émulateur et de lancer une UI. car cela ne dépend pas (ou ne devrait pas) dépendre du framework Android.
Cependant, le sujet testé peut dépendre d'autres pour que cela fonctionne. Pour instance, un ViewModel peut dépendre d'un dépôt de données pour fonctionner.
Lorsque vous devez fournir une dépendance à un sujet testé, une pratique courante consiste à créer un double de test (ou un objet de test). Les doubles de test sont des objets et agissent comme des composants de votre application, mais ils sont créés dans votre test pour fournir un comportement ou des données spécifiques. Leurs principaux avantages sont des tests plus rapides et plus simples.
Types de doubles de test
Il existe différents types de doubles de test:
| Falsifié | Un double de test avec un libellé "fonctionnel" de la classe, mais celle-ci est implémentée d'une manière qui la rend adaptée aux tests, mais n'est pas adaptée à la production.
Exemple: base de données en mémoire. Les faux ne nécessitent pas de framework de simulation et sont légers. Ils sont à privilégier. |
|---|---|
| Simulation | Double de test dont le comportement est défini comme vous le programmez et qui a des attentes concernant ses interactions. Les simulations échoueront aux tests si leurs interactions ne correspondent pas aux exigences que vous définissez. Les simulations sont généralement créées à l'aide d'un framework de simulation à cette fin.
Exemple: Vérifier qu'une méthode d'une base de données a été appelée exactement une fois. |
| Stub | Double de test qui se comporte comme vous le programmez, mais qui n'a aucune attente concernant ses interactions. Généralement créé avec un framework de simulation. Pour plus de simplicité, les faux sont préférables aux bouchons. |
| Factice | Double de test transmis, mais non utilisé (par exemple, si vous avez juste besoin de le fournir en tant que paramètre).
Exemple: Une fonction vide transmise en tant que rappel de clic. |
| Espionnage | Un wrapper sur un objet réel qui assure également le suivi de certaines informations supplémentaires, semblables à des simulations. Elles sont généralement évitées pour ajouter de la complexité. Les faux ou les simulations sont donc privilégiés par rapport aux espions. |
| Ombre | Faux utilisé chez Robolectric. |
Exemple d'utilisation d'un faux
Supposons que vous souhaitiez effectuer un test unitaire d'un ViewModel qui dépend d'une interface.
appelé UserRepository et expose le nom du premier utilisateur à une interface utilisateur. Vous pouvez
créer un faux double de test en implémentant l'interface et en renvoyant
données.
object FakeUserRepository : UserRepository {
fun getUsers() = listOf(UserAlice, UserBob)
}
val const UserAlice = User("Alice")
val const UserBob = User("Bob")
Cette fausse UserRepository n'a pas besoin de dépendre des données locales et distantes
que la version de production utilisera. Le fichier se trouve dans la source de test
et ne sera pas livré avec l'application de production.
Le test suivant vérifie que le ViewModel expose correctement le premier utilisateur à la vue.
@Test
fun viewModelA_loadsUsers_showsFirstUser() {
// Given a VM using fake data
val viewModel = ViewModelA(FakeUserRepository) // Kicks off data load on init
// Verify that the exposed data is correct
assertEquals(viewModel.firstUserName, UserAlice.name)
}
Le remplacement de UserRepository par un faux est facile dans un test unitaire, car
ViewModel est créé par le testeur. Toutefois, il peut être difficile de remplacer
des éléments arbitraires
dans les tests plus importants.
Remplacement des composants et injection de dépendances
Lorsque les tests n'ont aucun contrôle sur la création des systèmes testés, le remplacement des composants pour les doubles de test est plus complexe et nécessite de votre application afin de respecter une conception testable.
Même les grands tests de bout en bout peuvent bénéficier de l'utilisation de doubles de test, comme test d'interface utilisateur instrumenté qui parcourt un flux utilisateur complet dans votre application. Dans Dans ce cas, il peut être judicieux de rendre votre test hermétique. Un test hermétique permet d'éviter toutes les dépendances externes, comme la récupération de données sur Internet. Ce améliore la fiabilité et les performances.
<ph type="x-smartling-placeholder">
Vous pouvez concevoir manuellement votre application pour obtenir cette flexibilité, mais nous vous recommandons Utiliser un framework d'injection de dépendances comme Hilt pour remplacer les composants dans votre application au moment du test. Consultez le guide des tests Hilt.
Robolectric
Sous Android, vous pouvez utiliser le framework Robolectric, qui fournit un type spécial de double de test. Robolectric vous permet d'exécuter vos tests sur sur votre station de travail ou dans votre environnement d'intégration continue. Elle utilise un une machine virtuelle Java standard, sans émulateur ni appareil. Elle simule un gonflement des vues, le chargement des ressources et d'autres parties du framework Android avec des doubles de test appelées ombres.
Robolectric est un simulateur. Il ne doit donc pas remplacer de simples tests unitaires ni être utilisé. pour effectuer des tests de compatibilité. Rapidité et réduction des coûts de basse fidélité dans certains cas. Une bonne approche pour les tests de l'interface utilisateur consiste à les rendre compatible avec les tests Robolectric et instrumentés, et décidez quand l'exécuter en fonction de la nécessité de tester les fonctionnalités ou la compatibilité. Espresso et Compose peuvent s'exécuter sur Robolectric.