BDD en C# : comment écrire des tests que le métier comprend

BDD en C# : quand les tests parlent le langage du métier

Imaginez : vous êtes développeur C#. Un product owner vient vous voir et vous dit : « Faites en sorte qu'après le paiement d'une commande, l'utilisateur reçoive un email, mais uniquement si le montant dépasse 1000 roubles ». Vous acquiescez, vous vous mettez au code, vous écrivez la logique, vous la couvrez de tests unitaires. Une semaine plus tard, vous montrez le résultat. Le PO regarde, fronce les sourcils et dit : « Ce n'est pas ce que je voulais dire ».

Ça vous parle ? C'est le problème classique du fossé entre le métier et le développement. Et c'est exactement ce que résout le BDD en C# — Behaviour-Driven Development, ou développement piloté par le comportement.

Dans cet article, nous allons voir ce qu'est le BDD, en quoi il diffère du TDD, et surtout comment intégrer le BDD dans un projet C# avec SpecFlow et xUnit. Vous verrez des exemples de code concrets, apprendrez à écrire des scénarios en Gherkin et à les transformer en tests automatisés. C'est parti !

Qu'est-ce que le BDD et pourquoi en a-t-on besoin ?

BDD (Behaviour-Driven Development) est une méthodologie de développement dans laquelle les exigences du système sont décrites à travers le comportement de l'utilisateur. Au lieu de spécifications techniques arides, vous écrivez des scénarios en langage naturel, compréhensibles à la fois par le métier et par le développeur.

L'idée clé du BDD : « Ne vérifiez pas que le code fonctionne. Vérifiez que le système se comporte comme le métier l'attend ».

Contrairement au TDD (Test-Driven Development), où vous écrivez d'abord un test unitaire, puis le code, le BDD se concentre sur les scénarios d'utilisation. Les tests BDD ne vérifient pas une méthode ou une classe, mais un scénario utilisateur complet.

Les trois piliers du BDD

\n
• Un langage commun — tous les participants du projet (PO, analyste, testeur, développeur) parlent le même langage. Généralement, il s'agit de Gherkin.
\n
• Des scénarios — chaque élément fonctionnel est décrit via Given-When-Then (Étant donné-Quand-Alors).
\n
• Automatisation — les scénarios sont transformés en tests automatisés qui s'exécutent dans le cadre du CI/CD.
\n

Voyons maintenant à quoi cela ressemble en code C#.

Outils pour le BDD en C#

Pour implémenter le BDD dans l'écosystème .NET, il existe deux outils principaux :

\n
• SpecFlow — le framework BDD le plus populaire pour C#. Il analyse les scénarios Gherkin et les lie au code.
\n
• xUnit / NUnit / MSTest — des exécuteurs de tests qui lancent les tests BDD.
\n

Nous allons utiliser SpecFlow + xUnit. L'installation est simple — via NuGet :

dotnet add package SpecFlow\ndotnet add package SpecFlow.xUnit\ndotnet add package xunit\ndotnet add package xunit.runner.visualstudio

Après l'installation, créez un dossier Features dans votre projet — c'est là que vivront vos fichiers .feature contenant les scénarios.

Écrire notre premier scénario BDD en Gherkin

Gherkin est un langage de description du comportement. Il utilise les mots-clés : Feature, Scenario, Given, When, Then, And, But.

Décrivons un scénario simple : un utilisateur tente de payer une commande, et si le montant dépasse 1000 roubles, il reçoit un email.

Créez un fichier Payment.feature dans le dossier Features :

Feature: Notification de paiement\n    En tant que client\n    Je veux recevoir un email après un paiement\n    Afin d'avoir une confirmation de mon achat\n\nScenario: Un paiement réussi de plus de 1000 roubles envoie une notification\n    Étant donné un client avec un solde de 5000 roubles\n    Quand le client paie une commande de 1500 roubles\n    Alors le client devrait recevoir une notification par email\n\nScenario: Un paiement de moins de 1000 roubles n'envoie pas de notification\n    Étant donné un client avec un solde de 5000 roubles\n    Quand le client paie une commande de 500 roubles\n    Alors le client ne devrait recevoir aucune notification par email

Notez bien : ici