Cet article est le dernier d'une série sur l'application du modèle architectural MVI dans Kotlin Multiplatform. Dans les deux parties précédentes ( partie 1 et partie 2 ), nous nous sommes souvenus de ce qu'est MVI, avons créé un module générique Kittens pour charger des images de chat et l'avons intégré dans les applications iOS et Android.



Dans cette partie, nous aborderons le module Kittens avec des tests unitaires et d'intégration. Nous découvrirons les limites actuelles des tests dans Kotlin Multiplatform, découvrirons comment les surmonter et même les faire fonctionner à notre avantage.



Un exemple de projet mis à jour est disponible sur notre GitHub .

Prologue

Il ne fait aucun doute que les tests sont une étape importante du développement logiciel. Bien sûr, cela ralentit le processus, mais en même temps:

• vous permet de vérifier les cas de bord qui sont difficiles à attraper manuellement;
  
  
• Réduit les risques de régression lors de l'ajout de nouvelles fonctionnalités, de la correction de bugs et de la refactorisation;
  
  
• vous oblige à décomposer et structurer votre code.
  
  

À première vue, le dernier point peut sembler un inconvénient, car cela prend du temps. Cependant, cela rend le code plus lisible et plus avantageux à long terme.

«En effet, le rapport entre le temps passé à lire et à écrire est bien supérieur à 10 pour 1. Nous lisons constamment l'ancien code dans le cadre de l'effort d'écriture de nouveau code. ... [Par conséquent,] le rendre facile à lire le rend plus facile à écrire. " - Robert C. Martin, "Clean Code: A Handbook of Agile Software Craftsmanship"

Kotlin Multiplatform étend les capacités de test. Cette technologie ajoute une caractéristique importante: chaque test est automatiquement effectué sur toutes les plates-formes prises en charge. Si, par exemple, seuls Android et iOS sont pris en charge, le nombre de tests peut être multiplié par deux. Et si, à un moment donné, la prise en charge d'une autre plate-forme est ajoutée, elle est automatiquement couverte par les tests. 



Les tests sur toutes les plates-formes prises en charge sont importants car il peut y avoir des différences dans le comportement du code. Par exemple, Kotlin / Native a un modèle de mémoire spécial , Kotlin / JS donne aussi parfois des résultats inattendus.



Avant d'aller plus loin, il convient de mentionner certaines des limites des tests de Kotlin Multiplatform. Le plus important est l'absence de bibliothèque moqueuse pour Kotlin / Native et Kotlin / JS. Cela peut sembler un gros inconvénient, mais je le considère personnellement comme un avantage. Tester dans Kotlin Multiplatform a été assez difficile pour moi: j'ai dû créer des interfaces pour chaque dépendance et écrire leurs implémentations de test (faux). Cela a pris du temps, mais à un moment donné, j'ai réalisé que passer du temps sur les abstractions est un investissement qui conduit à un code plus propre. 



J'ai également remarqué que les modifications ultérieures de ce code prennent moins de temps. Pourquoi donc? Parce que l'interaction d'une classe avec ses dépendances n'est pas clouée (moquée). Dans la plupart des cas, il suffit de simplement mettre à jour leurs implémentations de test. Vous n'avez pas besoin d'approfondir chaque méthode de test pour mettre à jour vos simulations. En conséquence, j'ai arrêté d'utiliser des bibliothèques moqueuses même dans le développement Android standard. Je recommande de lire l'article suivant: " Se moquer n'est pas pratique - Utiliser des faux " de Pravin Sonawane .

Plan

Souvenons-nous de ce que nous avons dans le module Kittens et de ce que nous devons tester.

• KittenStore est le composant principal du module. Son implémentation KittenStoreImpl contient la plupart de la logique métier. C'est la première chose que nous allons tester.
  
  
• KittenComponent est la façade du module et le point d'intégration pour tous les composants internes. Nous couvrirons ce composant avec des tests d'intégration.
  
  
• KittenView est une interface publique qui représente la dépendance d'interface utilisateur de KittenComponent.
  
  
• KittenDataSource est une interface d'accès Web interne qui a des implémentations spécifiques à la plate-forme pour iOS et Android.
  
  

Pour une meilleure compréhension de la structure du module je vais donner son diagramme UML:







Le plan est le suivant:

• Tester KittenStore
  • Création d'une implémentation de test de KittenStore.Parser
    
    
  • Création d'une implémentation de test de KittenStore.Network
    
    
  • Rédaction de tests unitaires pour KittenStoreImpl
    
    
  
  
  
• Tester le composant Kitten
  • Création d'une implémentation de test de KittenDataSource
    
    
  • Créer une implémentation de test KittenView
    
    
  • Rédaction de tests d'intégration pour KittenComponent
    
    
  
  
  
• Exécution de tests
  
  
• conclusions
  
  

Tests unitaires KittenStore

L'interface KittenStore a sa propre classe d'implémentation - KittenStoreImpl. C'est ce que nous allons tester. Il a deux dépendances (interfaces internes), définies directement dans la classe elle-même. Commençons par écrire des implémentations de test pour eux.

Tester l'implémentation de KittenStore.Parser

Ce composant est responsable des requêtes réseau. Voici à quoi ressemble son interface:





Avant d'écrire une implémentation de test d'une interface réseau, nous devons répondre à une question importante: quelles données le serveur renvoie-t-il? La réponse est que le serveur renvoie un ensemble aléatoire de liens d'images, à chaque fois un ensemble différent. Dans la vraie vie, le format JSON est utilisé, mais comme nous avons une abstraction Parser, nous ne nous soucions pas du format dans les tests unitaires.



Une implémentation réelle peut changer de flux, de sorte que les abonnés peuvent être gelés dans Kotlin / Native. Ce serait formidable de modéliser ce comportement pour vous assurer que le code gère tout correctement.



Ainsi, notre implémentation de test de Network devrait avoir les caractéristiques suivantes:

• doit retourner un ensemble non vide de lignes différentes pour chaque requête;
  
  
• le format de réponse doit être commun pour Network et Parser;
  
  
• devrait être en mesure de simuler des erreurs de réseau (peut-être devrait se terminer sans réponse);
  
  
• il devrait être possible de simuler un format de réponse invalide (pour vérifier les erreurs dans Parser);
  
  
• il devrait être possible de simuler les délais de réponse (pour vérifier la phase de démarrage);
  
  
• devrait être congelable dans Kotlin / Native (juste au cas où).
  
  

L'implémentation du test elle-même pourrait ressembler à ceci:





TestKittenStoreNetwork a un stockage de chaînes (tout comme un vrai serveur) et peut générer des chaînes. Pour chaque requête, la liste actuelle des lignes est codée en une seule ligne. Si la propriété "images" est nulle, alors Maybe se terminera simplement, ce qui devrait être considéré comme une erreur.



Nous avons également utilisé TestScheduler . Ce planificateur a une fonction importante: il gèle toutes les tâches entrantes. Ainsi, l'opérateur observeOn, utilisé en conjonction avec TestScheduler, gèlera le flux en aval, ainsi que toutes les données qui le traversent, comme dans la vraie vie. Mais en même temps, le multithreading ne sera pas impliqué, ce qui simplifie les tests et les rend plus fiables.



De plus, TestScheduler dispose d'un mode spécial "traitement manuel" qui nous permettra de simuler la latence du réseau.

Tester l'implémentation de KittenStore.Parser

Ce composant est responsable de l'analyse des réponses du serveur. Voici son interface:





Ainsi, tout ce qui est téléchargé sur le Web doit être converti en une liste de liens. Notre réseau concatène simplement les chaînes en utilisant un séparateur point-virgule (;), utilisez donc le même format ici.



Voici une implémentation de test:





Comme avec Network, TestScheduler est utilisé pour geler les abonnés et vérifier leur compatibilité avec le modèle de mémoire Kotlin / Native. Les erreurs de traitement des réponses sont simulées si la chaîne d'entrée est vide.

Tests unitaires pour KittenStoreImpl

Nous avons maintenant des implémentations de test de toutes les dépendances. Il est temps pour les tests unitaires. Tous les tests unitaires peuvent être trouvés dans le référentiel , ici je ne donnerai que l'initialisation et quelques tests eux-mêmes.



La première étape consiste à créer des instances de nos implémentations de test:





KittenStoreImpl utilise mainScheduler, donc l'étape suivante consiste à le remplacer:





Maintenant, certains tests peuvent être effectués. KittenStoreImpl doit charger les images immédiatement après leur création. Cela signifie qu'une demande réseau doit être terminée, sa réponse doit être traitée et l'état doit être mis à jour avec le nouveau résultat.





Ce que nous avons fait:

• images générées sur le réseau;
  
  
• créé une nouvelle instance de KittenStoreImpl;
  
  
• s'est assuré que l'état contient la liste correcte de chaînes.
  
  

Un autre scénario que nous devons envisager est d'obtenir KittenStore.Intent.Reload. Dans ce cas, la liste doit être rechargée depuis le réseau.





Étapes du test:

• générer des images sources;
  
  
• créer une instance de KittenStoreImpl;
  
  
• générer de nouvelles images;
  
  
• envoyer Intent.Reload;
  
  
• assurez-vous que la condition contient de nouvelles images.
  
  

Enfin, examinons le scénario suivant: lorsque l'indicateur isLoading est défini pendant le chargement des images.





Nous avons activé le traitement manuel pour TestScheduler - maintenant, les tâches ne seront pas traitées automatiquement. Cela nous permet de vérifier l'état en attendant une réponse.

Test d'intégration KittenComponent

Comme je l'ai mentionné ci-dessus, KittenComponent est le point d'intégration de l'ensemble du module. Nous pouvons le couvrir de tests d'intégration. Jetons un coup d'œil à son API:





Il existe deux dépendances, KittenDataSource et KittenView. Nous aurons besoin d'implémentations de test pour ces derniers avant de pouvoir commencer les tests.



Par souci d'exhaustivité, ce diagramme montre le flux de données à l'intérieur du module:

Tester l'implémentation de KittenDataSource

Ce composant est responsable des requêtes réseau. Il a des implémentations distinctes pour chaque plateforme, et nous avons besoin d'une autre implémentation pour les tests. Voici à quoi ressemble l'interface KittenDataSource:





TheCatAPI prend en charge la pagination, j'ai donc ajouté les arguments appropriés tout de suite. Sinon, il est très similaire à KittenStore.Network, que nous avons implémenté plus tôt. La seule différence est que nous devons utiliser le format JSON car nous testons du vrai code en intégration. Nous empruntons donc simplement l'idée de mise en œuvre:





Comme précédemment, nous générons différentes listes de chaînes qui sont encodées dans un tableau JSON à chaque requête. Si aucune image n'est générée, ou si les arguments de la requête sont erronés, Maybe se terminera simplement sans réponse.



La bibliothèque kotlinx.serialization est utilisée pour former un tableau JSON . À propos, le KittenStoreParser testé l' utilise pour le décodage.

Tester la mise en œuvre de KittenView

C'est le dernier composant pour lequel nous avons besoin d'une implémentation de test avant de pouvoir commencer les tests. Voici son interface:





C'est une vue qui prend juste des modèles et déclenche des événements, donc son implémentation de test est très simple:





Nous avons juste besoin de nous souvenir du dernier modèle accepté - cela nous permettra de vérifier l'exactitude du modèle affiché. Nous pouvons également distribuer des événements au nom de KittenView à l'aide de la méthode dispatch (Event), qui est déclarée dans la classe AbstractMviView héritée.

Tests d'intégration pour KittenComponent

L'ensemble complet des tests se trouve dans le référentiel , ici je ne donnerai que quelques-uns des plus intéressants.



Comme précédemment, commençons par instancier les dépendances et initialiser:





Actuellement, deux programmateurs sont utilisés pour le module: mainScheduler et computationScheduler. Nous devons les remplacer:





Nous pouvons maintenant écrire quelques tests. Vérifions d'abord le script principal pour nous assurer que les images sont chargées et affichées au démarrage:





Ce test est très similaire à celui que nous avons écrit lorsque nous avons examiné les tests unitaires pour KittenStore. Ce n'est que maintenant que l'ensemble du module est impliqué.



Étapes du test:

• générer des liens vers des images dans TestKittenDataSource;
  
  
• créer et exécuter KittenComponent;
  
  
• assurez-vous que les liens atteignent TestKittenView.
  
  

Autre scénario intéressant: les images doivent être rechargées lorsque KittenView déclenche l'événement RefreshTriggered.





Étapes:

• générer des liens sources vers des images;
  
  
• créer et exécuter KittenComponent;
  
  
• générer de nouveaux liens;
  
  
• envoyer Event.RefreshTriggered au nom de KittenView;
  
  
• assurez-vous que les nouveaux liens atteignent TestKittenView.
  
  

Exécution de tests

Pour exécuter tous les tests, nous devons effectuer la tâche Gradle suivante:

./gradlew :shared:kittens:build

Cela compilera le module et exécutera tous les tests sur toutes les plates-formes prises en charge: Android et iosx64.



Et voici le rapport de couverture JaCoCo:

Conclusion

Dans cet article, nous avons couvert le module Kittens avec des tests unitaires et d'intégration. La conception proposée du module nous a permis de couvrir les parties suivantes:

• KittenStoreImpl - contient la plupart de la logique métier;
  
  
• KittenStoreNetwork - responsable des requêtes réseau de haut niveau;
  
  
• KittenStoreParser - responsable de l'analyse des réponses du réseau;
  
  
• toutes les transformations et connexions.
  
  

Le dernier point est très important. Il est possible de le couvrir grâce à la fonctionnalité MVI. La seule responsabilité de la vue est d'afficher les données et d'envoyer des événements. Tous les abonnements, conversions et liens se font à l'intérieur du module. Ainsi, nous pouvons tout couvrir avec des tests généraux, à l'exception de l'affichage lui-même.



Ces tests présentent les avantages suivants:

• n'utilisez pas d'API de plateforme;
  
  
• exécuté très rapidement;
  
  
• fiable (ne clignote pas);
  
  
• s'exécuter sur toutes les plates-formes prises en charge.
  
  

Nous avons également pu tester la compatibilité du code avec le modèle de mémoire complexe Kotlin / Native. Ceci est également très important en raison du manque de sécurité au moment de la construction: le code se bloque juste à l'exécution avec des exceptions difficiles à déboguer.



J'espère que cela vous aidera dans vos projets. Merci d'avoir lu mes articles! Et n'oubliez pas de me suivre sur Twitter .

...

Exercice bonus

Si vous souhaitez travailler avec des implémentations de test ou jouer avec MVI, voici quelques exercices pratiques.

Refactoriser le KittenDataSource

Il existe deux implémentations de l'interface KittenDataSource dans le module: une pour Android et une pour iOS. J'ai déjà mentionné qu'ils sont responsables de l'accès au réseau. Mais ils ont en fait une autre fonction: ils génèrent l'URL de la requête en fonction des arguments d'entrée "limite" et "page". En même temps, nous avons une classe KittenStoreNetwork qui ne fait rien d'autre que de déléguer l'appel à KittenDataSource.



Affectation: déplacez la logique de génération de demande d'URL de KittenDataSourceImpl (sur Android et iOS) vers KittenStoreNetwork. Vous devez modifier l'interface KittenDataSource comme suit:







Une fois que vous avez fait cela, vous devrez mettre à jour vos tests. La seule classe que vous devez toucher est TestKittenDataSource.

Ajout du chargement de la page

TheCatAPI prend en charge la pagination, nous pouvons donc ajouter cette fonctionnalité pour une meilleure expérience utilisateur. Vous pouvez commencer par ajouter un nouvel événement Event.EndReached pour KittenView, après quoi le code arrêtera la compilation. Ensuite, vous devrez ajouter le Intent.LoadMore approprié, convertir le nouvel événement en Intent et traiter ce dernier dans KittenStoreImpl. Vous devrez également modifier l'interface KittenStoreImpl.Network comme suit:







Enfin, vous devrez mettre à jour certaines implémentations de test, corriger un ou deux tests existants, puis en écrire de nouveaux pour couvrir la pagination.