FR
RU
EN
ES
ZH
DE
PT
AR
HI
BDD sur Kotlin : Écrire des tests que lisent aussi bien les managers que les développeurs
\n\nAvez-vous déjà montré un test unitaire à votre chef de produit ? Probablement pas. Parce que c'est comme montrer les plans d'un moteur à réaction à un pilote : utile, mais incompréhensible. Le Behaviour-Driven Development (BDD) sur Kotlin résout précisément ce problème : il transforme les assert's arides en scénarios vivants qui décrivent le comportement du système en langage humain.
\n\nDans cet article, nous allons voir comment implémenter le BDD sur Kotlin à l'aide de frameworks modernes — Kotest et Spek. Vous verrez comment écrire des tests dans le style Given-When-Then, qui sont à la fois une documentation et une vérification automatique. Et oui, même votre chef d'équipe sans préparation pourra les lire.
\n\nQu'est-ce que le BDD et en quoi diffère-t-il du TDD ?
\n\nBeaucoup confondent TDD (Test-Driven Development) et BDD (Behaviour-Driven Development). La différence est simple :
\n\n- \n
- TDD — c'est « comment vais-je vérifier cette méthode ? » \n
- BDD — c'est « comment l'utilisateur va-t-il obtenir de la valeur de cette fonctionnalité ? » \n
Le Behaviour-driven development se concentre sur le comportement du système, et non sur les détails d'implémentation. Vous décrivez un scénario : dans des conditions données (Given), lorsqu'une action se produit (When), le système produit le résultat attendu (Then).
\n\nPar exemple, au lieu d'écrire : assertEquals(42, calculator.add(20, 22)),
vous écrivez :
Given("j'ai une calculatrice") {\n val calc = Calculator()\n When("j'additionne 20 et 22") {\n val result = calc.add(20, 22)\n Then("le résultat doit être 42") {\n result shouldBe 42\n }\n }\n}\nReconnaissez que la deuxième version se lit comme une histoire, et non comme une instruction technique.
\n\nPourquoi Kotlin est idéal pour le BDD
\n\nKotlin est un langage qui, par lui-même, se prête à l'écriture de code lisible. Les fonctions d'extension, la notation infixe, les lambdas avec récepteur — tout cela rend les tests BDD sur Kotlin extrêmement naturels. Vous pouvez écrire shouldBe, shouldThrow et d'autres matchers qui ressemblent à de l'anglais.
De plus, Kotlin prend en charge plusieurs paradigmes, ce qui permet d'utiliser différents frameworks pour le BDD. Examinons les deux plus populaires.
\n\nFramework Kotest : BDD intégré
\n\nKotest (anciennement KotlinTest) est un puissant framework de test multiplateforme. Il prend en charge plusieurs styles, dont BehaviorSpec, qui est parfaitement adapté au BDD.
\n\nVoici à quoi ressemble un scénario BDD complet sur Kotlin utilisant Kotest :
\n\nimport io.kotest.core.spec.style.BehaviorSpec\nimport io.kotest.matchers.shouldBe\n\nclass CartSpec : BehaviorSpec({\n given("panier vide") {\n val cart = ShoppingCart()\n `when`("on ajoute un article au prix de 100") {\n cart.addItem(Item("Livre", 100.0))\n then("le panier doit contenir 1 article") {\n cart.itemCount shouldBe 1\n }\n then("le montant total doit être de 100") {\n cart.total shouldBe 100.0\n }\n }\n `when`("on ajoute un article et on applique une réduction de 10%") {\n cart.addItem(Item("Livre", 100.0))\n cart.applyDiscount(10.0)\n then("le montant final doit être de 90") {\n cart.total shouldBe 90.0\n }\n }\n }\n})\nRemarquez les guillemets inversés autour de when. C'est une particularité de Kotlin : when est un mot réservé, mais entre guillemets, il fonctionne comme un identifiant. Certains développeurs préfèrent utiliser When avec une majuscule.
Spek : BDD structuré pour Kotlin
\n\nSpek
Blogs
Book Recommendations
Lire aussi
Comment écrire une API REST en Java en 30 minutes : guide étape par étape
Programmation asynchrone en C# : guide complet avec exemples
