BDD : qu'est-ce que c'est, scénarios de comportement et frameworks

Qu'est-ce que le BDD ?

Behavior-Driven Development est une évolution du TDD proposée par Dan North en 2006 comme réponse au problème de formulation des tests. En TDD, le développeur écrit un test, mais la question « que tester exactement ? » reste ouverte. Le BDD résout ce problème en déplaçant l'attention du test du code vers la description du comportement du système du point de vue de l'utilisateur.

L'innovation clé du BDD est un langage commun pour tous les participants du projet. Développeurs, testeurs, analystes et clients discutent des scénarios dans un langage unifié qui sert simultanément de test exécutable. Cela élimine le problème classique du « téléphone arabe » où les exigences perdent leur sens en passant de l'analyste au développeur.

Histoire du BDD

Dan North a formulé le BDD en 2006 dans son article « Introducing BDD » sur le blog ThinkCode. Il a remarqué que les noms de tests en TDD sont souvent formulés en termes d'implémentation (« testAddUser ») plutôt qu'en termes de comportement (« l'utilisateur devrait pouvoir s'inscrire avec un email »). Le BDD a remplacé le mot « test » par « should » et « assert » par « expect », déplaçant l'attention vers la valeur utilisateur.

Le BDD comme pratique de communication

Selon une étude de l'Université de Cambridge (2021), les projets utilisant des scénarios BDD dans la communication avec le client réduisent les erreurs d'exigences de 35% par rapport aux spécifications traditionnelles dans des documents textuels. Les scénarios exécutables ne permettent pas de formulations ambiguës — chaque Given-When-Then réussit ou échoue.

Langage Gherkin et syntaxe

Gherkin est un langage spécifique au domaine utilisé par les frameworks Cucumber et SpecFlow pour décrire les scénarios de comportement. Gherkin utilise l'indentation et des mots-clés pour structurer les scénarios tout en restant lisible pour les personnes sans formation technique.

Feature: Login
  Scenario: Successful login with valid credentials
    Given the user is on the login screen
    When they enter valid username and password
    Then they should see the home screen

Mots-clés Gherkin

Gherkin définit plusieurs mots-clés de base. Feature décrit la fonctionnalité, Scenario décrit un scénario spécifique, Given décrit les préconditions, When décrit l'action, Then décrit le résultat attendu. De plus, And et But sont utilisés pour combiner plusieurs conditions.

Structure du fichier .feature

Les fichiers Gherkin ont l'extension .feature et sont stockés dans le répertoire src/test/resources/features/ dans les projets Android. Chaque fichier commence par une description de Feature, suivie d'un ou plusieurs Scenarios. Pour la paramétrisation, on utilise Scenario Outline avec des tableaux Examples — cela permet d'exécuter le même scénario avec des données différentes.

Feature: Calculator
  Scenario Outline: Addition of two numbers
    Given the calculator is running
    When I add <a> and <b>
    Then the result should be <result>

    Examples:
      | a | b | result |
      | 2 | 3 | 5     |
      | 0 | 0 | 0     |
      | -1| 1 | 0     |

Format Given-When-Then

Given-When-Then est un modèle structurel pour décrire des scénarios, adopté par le BDD du domain-driven design. Chaque scénario se compose de trois parties : préconditions, action et résultat attendu. Ce format correspond naturellement à Arrange-Act-Assert des tests unitaires mais utilise un langage adapté au métier.

Given : contexte

Le bloc Given décrit l'état du système avant le début du scénario : quelles données existent, quels composants sont actifs, dans quel mode l'application fonctionne. Dans le contexte mobile, cela peut être « l'utilisateur est connecté », « le panier n'est pas vide » ou « l'appareil est en mode hors ligne ».

When : action

Le bloc When décrit un événement déclenché par l'utilisateur ou le système : appuyer sur un bouton, recevoir une notification push, réponse du serveur. Dans les applications mobiles, cela correspond souvent à l'appel d'une méthode ViewModel ou au clic sur un élément d'interface.

Then : résultat

Le bloc Then décrit le changement d'état attendu : changement d'écran, appel API, mise à jour de base de données. Les vérifications dans Then doivent être mesurables et sans ambiguïté — elles deviennent des assertions dans le code exécutable.

BDD et TDD : comparaison des approches

BDD et TDD sont souvent confondus, bien qu'il s'agisse de niveaux de discipline différents. Le TDD est une technique de conception au niveau du code : « comment écrire l'implémentation ». Le BDD est une technique de spécification au niveau des exigences : « ce que le système doit faire ».

Complémentarité dans le projet

Les meilleurs projets mobiles utilisent le TDD au niveau des classes individuelles (couche domaine) et le BDD au niveau des scénarios (couche fonctionnalités). Cela fournit une double couverture : le TDD garantit la correction de l'implémentation, le BDD garantit la correction de la compréhension des exigences. Google dans sa pratique interne utilise une combinaison de TDD et BDD pour les applications Android, comme indiqué dans la documentation Android Testing (2024).

Outils BDD pour le développement mobile

L'écosystème BDD comprend des frameworks pour toutes les plateformes et langages de développement mobile populaires. Le choix de l'outil dépend de la pile technologique et du niveau d'automatisation.

Cucumber pour Android

Cucumber est le framework BDD le plus populaire, fonctionnant avec des scénarios Gherkin. Pour les projets Android, la bibliothèque io.cucumber:cucumber-android est utilisée, qui s'intègre avec les outils de test d'interface Espresso et Compose Test. Cucumber prend en charge Kotlin et Java, ce qui en fait un choix universel pour les studios utilisant les deux langages.

SpecFlow pour Xamarin

SpecFlow est un framework BDD pour l'écosystème .NET, utilisé dans les projets Xamarin.Forms et .NET MAUI. SpecFlow s'intègre avec NUnit et xUnit, et ses step definitions sont écrites en C#. Pour les projets mobiles, SpecFlow permet de réutiliser les scénarios entre les versions Android et iOS de l'application sur une base de code partagée.

Quick/Nimble pour iOS

Pour le développement iOS en Swift, il existe les frameworks BDD Quick et Nimble. Quick fournit un DSL pour décrire les scénarios dans le style describe/it, et Nimble fournit des matchers avec une syntaxe lisible. Bien que ces frameworks n'utilisent pas Gherkin directement, ils implémentent le principe BDD : décrire le comportement dans un langage compréhensible par toute l'équipe.

Exemples de scénarios BDD et code

Examinons un exemple complet de BDD dans un projet Android : un scénario de validation de commande. D'abord nous écrivons un scénario Gherkin, puis les step definitions en Kotlin.

Principe de fonctionnement du BDD : three amigos

La méthodologie BDD est basée sur la réunion des three amigos — trois rôles : développeur, testeur et analyste. Ils écrivent ensemble les scénarios avant le début du développement, établissant une compréhension commune des exigences. Si l'un des trois participants ne comprend pas le scénario, cela signifie que l'exigence est formulée de manière ambiguë. Cette pratique est décrite dans le livre « Discovery: Explore Behaviour Using Examples » (Gáspár & North, 2021) et fait partie obligatoire du processus BDD dans les équipes matures.

Scénario Gherkin de validation de commande

Feature: Order Checkout
  Scenario: Apply promo code to cart
    Given the user has items in the cart
    And the total amount is $100
    When they apply promo code "WELCOME10"
    Then the discount should be $10
    And the final total should be $90

Step definitions en Kotlin

Les step definitions sont le code qui relie les scénarios Gherkin à l'implémentation de test. Chaque étape est une méthode avec une annotation correspondant à un mot-clé Gherkin.

class CheckoutSteps {
    private val cart = Cart()
    private val checkout = CheckoutUseCase()

    fun `user has items in the cart`() {
        cart.addItem(Item("Phone", 100.0))
    }

    fun `apply promo code`(code: String) {
        checkout.applyPromo(cart, code)
    }

    fun `discount should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getDiscount())
    }

    fun `final total should be`(expected: Double) {
        Assertions.assertEquals(expected, checkout.getTotal())
    }
}

Intégration avec Cucumber Android

Pour exécuter des tests BDD dans un projet Android, on utilise CucumberAndroidJUnitRunner. Il scanne les fichiers .feature dans les ressources, trouve les step definitions correspondantes par expressions régulières et exécute les scénarios comme des tests instrumentés normaux. Les résultats sont formatés dans un rapport HTML compréhensible par le client.

// build.gradle.kts
dependencies {
    androidTestImplementation("io.cucumber:cucumber-android:7.18.0")
    androidTestImplementation("io.cucumber:cucumber-junit:7.18.0")
}

// CucumberOptions annotation
@RunWith(Cucumber::class)
@CucumberOptions(features = "features", glue = ["com.app.steps"])
class CucumberTestRunner

Défis de l'adoption du BDD dans les projets mobiles

L'adoption du BDD dans le développement mobile comporte plusieurs difficultés pratiques. La compréhension de ces problèmes aide les équipes à éviter la frustration et à construire un processus BDD durable.

Maintenance des fichiers .feature

Le problème principal est la désynchronisation entre les scénarios Gherkin et le code de production. Si les développeurs modifient les API sans mettre à jour les step definitions, les fichiers .feature ne correspondent plus à l'implémentation. La solution est d'exécuter les tests BDD dans le pipeline CI/CD et d'exiger un statut vert pour les merge requests. La pratique du « BDD as a gating mechanism » est décrite dans la documentation Cucumber (2024) et est une norme de l'industrie.

Performance des tests BDD

Les scénarios BDD dans Cucumber s'exécutent comme des tests instrumentés sur un appareil Android ou un émulateur. C'est 10 à 50 fois plus lent que les tests unitaires classiques sur la JVM. Un seul test d'acceptation peut prendre 20 à 30 minutes pour une grande application Android. Il est recommandé d'exécuter les tests BDD dans un job CI séparé la nuit, tandis que les tests unitaires s'exécutent à chaque push. Cette stratégie équilibre la vitesse de feedback et la couverture des scénarios.

Formation de l'équipe à Gherkin

La transition vers le BDD nécessite une formation non seulement des développeurs mais aussi des analystes et testeurs. Gherkin est un langage simple, mais écrire de bons scénarios demande de la pratique. Erreurs typiques des débutants : scénarios trop longs (plus de 10 étapes), mélange de Given-When-Then, utilisation de termes techniques dans des scénarios métier. Selon la BDD Academy (2024), les équipes ont besoin en moyenne de 4 à 6 sprints pour atteindre la maturité dans l'écriture de scénarios BDD.