Les projets Kotlin Multiplatform vous permettent de partager facilement la logique métier entre les différents niveaux de votre système. Mais comment tester facilement votre code tout en prenant en considération les spécificités des plates-formes que vous ciblez ?
Structurer votre application comme modulaire peut être très bénéfique pour la santé de votre base de code. En particulier, la conception d’une séparation entre la logique de vue et la logique métier peut réduire l’interdépendance entre vos couches et améliorer la maintenabilité ainsi que la testabilité.
Les tests sont en effet les meilleurs amis de votre application, car ils peuvent, à la fois, vérifier que le code que vous avez écrit fonctionne comme prévu et servir de spécification pour la fonctionnalité implémentée.
En ce qui concerne Multiplatform, Kotlin fournit une solution intéressante pour tester votre logique: dans cette configuration, chaque test écrit est exécuté sur chacune des plates-formes ciblées. Par exemple, si vous souhaitez tester en même temps Android et iOS (via Kotlin/Native), vos tests seront compilés et lancés à la fois dans la JVM et dans l’environnement d’exécution natif.
La configuration des tests unitaires pour Multiplatform peut cependant être un peu complexe : nous verrons donc, par la suite, comment obtenir une configuration fonctionnelle.
Pour ce faire, nous allons partir de notre dernier post sur la création de modules partagés entre iOS et Android.
Comme vous vous en souvenez peut-être, notre module n’a fait que produire deux chaînes de caractères, "bar-android" et "bar-ios" pour Android et iOS respectivement ; grâce aux test de Kotlin Multiplatform, nous serons en mesure de vérifier que, peu importe la plate-forme ciblée, la valeur produite commence par "bar-".
Pour mieux suivre les étapes suivantes, vous pouvez visionner le code décrit au cours de cet article à l’intérieur de notre depot GitHub, sur la branche feature/multiplatform.
Il est temps de coder
Ajoutons maintenant un nouveau test. Tout d’abord, créons le dossier qui contiendra notre test: myframework/src/test/kotlin/fr/xebia/myframework/. Comme vous pouvez vous y attendre, le chemin est similaire à celui qui héberge notre logique métier. Dans ce répertoire, nous allons insérer une nouvelle classe de test, TestFoo, avec les contenus suivants :
package fr.xebia.myframework
import kotlin.test.*
class TestFoo {
// L'annotation “@Test” permet à Kotlin de reconnaitre la fonction en tant que test
@Test
fun testBar() {
val foo = Foo()
// The assert to be verified
assertTrue {
foo.bar().startsWith("bar-")
}
}
}
Comme vous l’avez vu, Kotlin se compose d’un framework de test et d’assertions, donc pas besoin de déclarer une autre dépendance à votre projet.
Bien sûr, pour que les tests soient exécutés, nous devons éditer nos fichiers build.gradle. Commençons par le projet common : il devra déclarer deux dépendances supplémentaires: kotlin-test-common et kotlin-test-annotations.
Veuillez noter que, dans Kotlin Multiplatform, puisque les tests ne peuvent être exécutés que sur une plate-forme cible spécifique (comme la JVM d’Android, par exemple), kotlin-test-common ne sera pas suffisant pour lancer vos tests et nécessitera donc d’un framework de test concret, spécifique à la plate-forme, tel que JUnit. Autrement dit, les tests que vous écrirez dans la couche common ne seront qu’une implémentation abstraite de votre logique de vérification ; cette dernière sera rendue concrète par les couches platform de votre projet.
Pour valider cela, nous pouvons déjà essayer de compiler les tests, qui produiront une erreur de construction, car la cible de la plateforme ne saura pas comment interpreter les annotations et les assertions.
build.gradle pour Android
Vous l’aurez compris, nous devrons aussi éditer le fichier build.gradle pour le projet Android. De même que pour celui inclus dans le projet common, le fichier de construction Android doit déclarer des dépendances supplémentaires, nécessaires à la correcte execution des tests : junit, kotlin-test-junit et kotlin-test.
build.gradle pour iOS
Pour terminer, nous devons maintenant compléter le fichier Gradle pour le projet Kotlin/Native utilisé sur iOS, dont la configuraiton est définitivement plus compliquée.
Dans la version actuelle de Kotlin/Native, pour que les tests soient lancés, nous devrons créer un programme « fictif » qui contiendra à la fois notre code main et test et qui sera exécuté lors de l’exécution de la tâche test de Gradle.
Pour ce faire, ajoutons un nouveau programme dans le fichier build.gradle contenu dans notre dossier myframework-ios:
program('shared-ios-test') {
srcDir 'src/main/kotlin'
srcDir 'src/test/kotlin'
commonSourceSets 'main', 'test'
extraOpts '-tr'
enableMultiplatform true
}
Deuxièmement, nous devons demander à Gradle de lancer le programme au lancement de gradle test. Pour ce faire, nous devrons ajouter une nouvelle tâche, en bas du fichier:
task test(dependsOn: run)
Bien sûr, vous pouvez récupérer le code complet du fichier de construction sur GitHub.
Lors de l’exécution du test gradle, notre programme compilera, sera exécuté et produira la sortie suivante:
[==========] Running 1 tests from 1 test cases. [----------] Global test environment set-up. [----------] 1 tests from fr.xebia.myframework.TestFoo [ RUN ] fr.xebia.myframework.TestFoo.testBar [ OK ] fr.xebia.myframework.TestFoo.testBar (0 ms) [----------] 1 tests from fr.xebia.myframework.TestFoo (0 ms total) [----------] Global test environment tear-down [==========] 1 tests from 1 test cases ran. (0 ms total) [ PASSED ] 1 tests.
Aller plus loin
Une caractéristique intéressante d’une telle configuration est que nous pouvons ajouter des tests spécifiques pour chaque plate-forme. Par exemple, dans le cas où nous voulons ajouter un test plus détaillé pour notre cible Kotlin/Native, nous aurons juste besoin de créer un nouveau dossier de test dans le sous-projet myframework-ios – sans oublier d’ajouter un tel dossier à srcDir .gradle.
Bien sûr, les tests montrés dans cet article peuvent être lancés depuis votre
Conclusion
Comme nous l’avons vu, la configuration d’un environnement de test pour les tests Multiplatform est juste une question d’ajout de quelques lignes de code. Une fois que nous aurons la bonne configuration, les tests seront effectués sur toutes les plates-formes ciblées avec peu d’effort.