TDD en Kotlin : écrire du code sans peur et sans reproche

Pourquoi le TDD n'est pas une énième méthodologie à la mode, mais votre nouvelle cape de super-héros

Imaginez : vous écrivez du code comme un artiste — touche après touche, ligne après ligne. Vous êtes convaincu que tout est génial. Mais une heure passe, vous lancez l'application, et elle plante avec une erreur que vous chercheriez une demi-journée. Ça vous parle ?

Imaginez maintenant un autre scénario. Vous écrivez d'abord un test qui échouera à coup sûr. Ensuite — le code minimal pour que le test réussisse. Et seulement après — vous refactorez, améliorez, mais avec la conscience tranquille. C'est ce qu'on appelle le développement piloté par les tests (TDD), et en Kotlin, cela devient un véritable plaisir.

Dans cet article, nous n'allons pas faire de cours ennuyeux. Nous allons prendre un exemple concret, parcourir les trois étapes du TDD (Red — Green — Refactor) et montrer comment écrire du code fiable sans peur et sans reproche. Prêt ? C'est parti !

TDD : trois lettres qui vont changer votre code

TDD (Test-Driven Development) n'est pas qu'une simple technique, c'est une philosophie. Le principe est simple : d'abord le test, ensuite le code. Ça semble fou ? À première vue, oui. En pratique, cela économise des heures de débogage.

Le cycle du développement piloté par les tests

• Red — on écrit un test qui échoue (il doit planter).
• Green — on écrit le code minimal pour que le test réussisse.
• Refactor — on améliore le code sans changer son comportement.

Et ainsi de suite, en petits pas. Chaque pas est une certitude que vous n'avez rien cassé. En Kotlin, avec sa syntaxe concise et sa sécurité null, le TDD devient encore plus agréable.

Outillage : ce qu'il faut pour le TDD en Kotlin

Avant de plonger dans le code, préparons notre arsenal. Pour les tests unitaires en Kotlin, vous aurez besoin de :

• JUnit 5 — le standard de facto pour les tests unitaires.
• MockK — une bibliothèque de mocks conçue spécialement pour Kotlin (fini les problèmes avec null et les companion object).
• Gradle ou Maven — pour la gestion des dépendances.

Ajoutez dans build.gradle.kts :

dependencies {    testImplementation("org.junit.jupiter:junit-jupiter:5.10.0")    testImplementation("io.mockk:mockk:1.13.8")}

Voilà. Maintenant, on peut écrire du code dont on n'aura pas honte de montrer à ses collègues.

Écrivons notre premier cycle TDD : une calculatrice ambitieuse

Commençons par un classique — une calculatrice. Mais pas une simple, une qui supporte les opérations sur chaînes. Objectif : la fonction calculate prend une chaîne comme "2 + 3" et retourne 5.

Étape 1 : Red — on écrit un test qui échoue

Créons la classe de test :

import org.junit.jupiter.api.Testimport org.junit.jupiter.api.Assertions.assertEquals

class CalculatorTest {

    @Test    fun `should add two numbers`() {        val calculator = StringCalculator()        val result = calculator.calculate("2 + 3")        assertEquals(5, result)    }}

On lance le test — il échoue, car la classe StringCalculator n'existe pas encore. Signal rouge — tout se passe comme prévu.

Étape 2 : Green — le code minimal pour réussir

On écrit juste assez pour que le test passe. Pas de fioritures architecturales :

class StringCalculator {    fun calculate(expression: String): Int {        val parts = expression.split(" + ")        return parts[0].toInt() + parts[1].toInt()    }}

Maintenant le test est vert. Hourra ! Mais le code est encore moche — il ne gère que l'addition de deux nombres.

Étape 3 : Refactor — rendons le code beau

On refactore sans changer le comportement. On ajoute le support de différentes opérations, on extrait la logique dans des fonctions séparées :

class StringCalculator {    fun calculate(expression: String): Int {        val (a, op, b) =