Test Kotlin : par où commencer pour un débutant — guide complet

Introduction : Pourquoi les tests Kotlin sont un super-pouvoir, et non une corvée ennuyeuse

Imaginez : vous avez écrit une application en Kotlin. Elle fonctionne. Vous êtes heureux. Mais une semaine passe, vous ajoutez une nouvelle fonctionnalité — et soudain, l'ancienne se casse. Cela vous dit quelque chose ? Si non, vous êtes soit un génie, soit vous n'avez jamais écrit de code sans tests. Les tests Kotlin ne sont pas simplement une case à cocher dans la liste du développeur. C'est votre « bouclier » personnel contre les bugs, un moyen de dormir tranquille après le déploiement et un outil qui rend le code plus propre et plus compréhensible.

Dans cet article, je vais vous montrer par où commencer les tests en Kotlin pour un développeur débutant. Nous analyserons des exemples concrets, des bibliothèques populaires et des astuces qui vous feront gagner des heures de débogage. Vous apprendrez à écrire des tests unitaires, à simuler des dépendances et à tester les coroutines. C'est parti !

Étape 1 : Configuration de l'environnement — les 5 premières minutes

Avant d'écrire votre premier test, vous devez ajouter les dépendances. Si vous utilisez Gradle (et c'est probablement le cas), ajoutez les lignes suivantes dans build.gradle.kts :

// build.gradle.kts\ndependencies {\n    // JUnit 5 — la base des tests unitaires\n    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")\n    \n    // MockK — la meilleure bibliothèque pour les mocks en Kotlin\n    testImplementation("io.mockk:mockk:1.13.8")\n    \n    // AssertJ — des assertions élégantes et lisibles\n    testImplementation("org.assertj:assertj-core:3.24.2")\n    \n    // Pour tester les coroutines\n    testImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-test:1.7.3")\n}\n\ntasks.test {\n    useJUnitPlatform()\n}

Voilà ! Vous avez maintenant tout le nécessaire pour écrire des tests. Notez que nous utilisons JUnit 5 (et non 4) — c'est le standard moderne qui s'entend parfaitement avec Kotlin. MockK n'est pas choisi au hasard : il comprend la null-safety, les fonctions d'extension et autres spécificités de Kotlin avec lesquelles Mockito a du mal.

Étape 2 : Votre premier test unitaire en Kotlin

Écrivons une classe simple et testons-la. Supposons que nous ayons un calculateur de remise :

// DiscountCalculator.kt\nclass DiscountCalculator {\n    fun calculateDiscount(price: Double, discountPercent: Int): Double {\n        require(price >= 0) { "Le prix ne peut pas être négatif" }\n        require(discountPercent in 0..100) { "La remise doit être comprise entre 0 et 100" }\n        return price * (100 - discountPercent) / 100.0\n    }\n}

Écrivons maintenant le test. Créez un fichier DiscountCalculatorTest.kt dans le dossier src/test/kotlin :

import org.junit.jupiter.api.Test\nimport org.junit.jupiter.api.assertThrows\nimport org.assertj.core.api.Assertions.assertThat\n\nclass DiscountCalculatorTest {\n    \n    private val calculator = DiscountCalculator()\n    \n    @Test\n    fun `doit calculer correctement une remise de 20%`() {\n        val result = calculator.calculateDiscount(1000.0, 20)\n        assertThat(result).isEqualTo(800.0)\n    }\n    \n    @Test\n    fun `doit lever une exception pour un prix négatif`() {\n        assertThrows<IllegalArgumentException> {\n            calculator.calculateDiscount(-100.0, 10)\n        }\n    }\n    \n    @Test\n    fun `doit retourner le prix total pour une remise de 0%`() {\n        val result = calculator.calculateDiscount(500.0, 0)\n        assertThat(result).isEqualTo(500.0)\n    }\n}

Remarquez le style : nous utilisons des guillemets inversés pour les noms de tests en français (Kotlin le permet). Cela rend les tests lisibles même pour un collègue non technique. AssertJ offre une interface fluide : assertThat(result).isEqualTo(800.0) — se lit comme une phrase en français.

Étape 3 : Mocks avec MockK — quand on teste les dépendances

Dans les applications réelles, les classes vivent rarement seules. Elles accèdent à des bases de données, des API ou d'autres services. Pour ne pas dépendre des systèmes externes, nous utilisons des mocks. Supposons que nous ayons un service de