Introduction au BDD (Behavior-Driven Development)Ou comment passer le TDD (Test-Driven Development) sous stéroïdes

Qui suis-je ? Intrigué et intéressé par les ordinateurs et la technologie depuis 1984

Premier site web professionnel en 1995 Professionnel de l’IT depuis 1999 Spécialiste .NET depuis 2005 Consultant depuis 2007 Fondateur et CTO de différentes sociétés

Connectons sur LinkedIn Suivez moi sur Twitter (@fvilers)

Exemple concret Penser à la dernière fois que vous avez utilisé une application sur votre téléphone ou ordinateur

Donner une exemple de la dernière utilisation que vous avez fait de Twitter

Visualisez un cas concret d’utilisation d’une fonctionnalité, avec tous les détails

Était-ce assez concret cette fois-ci ?

En quelques mots… Processus d’exploration, de découverte, de définition, et de mise au point du design et du comportement d’un système informatique utilisant la conversation, des exemples concrets et des tests automatisés afin de partager une compréhension commune.

Qu’est-ce que c’est ? Combine et étend le TDD et le « Domain-Driven Design » (DDD) Les scénarios sont écrits avant le code Ils font partie intégrante de l’« ubiquitous language » (langage

omniprésent/universel) Le scénario est transformé en tests exécutables Idéal pour les tests d’acceptation Utilise une syntaxe légère (« Gherkin » – une variété de concombre) Modifie l’approche des tests en proposant l’utilisation d’une langue naturelle

Pourquoi en parler aujourd’hui ? Requiert un processus Agile Les scénarios sont mis au point « just in time » (au dernier moment) Les scénarios suivent la structure des « user stories » L’écriture des scénarios est ordonnée selon la valeur métier des fonctionnalités

L’équipe de réalisation et les « stakeholders » peuvent être impliqués

Est-ce si différent du TDD ? En TDD, pour chaque unité de code, le développeur devra : Ecrire un jeu de test correspondant Implémenter l’unité de code Vérifier que l’implémentation passe les tests Les tests unitaires attestent de la conformité technique de bas niveau Le BDD permet d’écrire des tests plus fonctionnels où l’on s’assure du bon comportement du code, et donc du besoin exprimé par le métier

Le BDD encourage les analystes et les développeurs à collaborer plus étroitement dans la rédaction des « user stories »

Comment rédiger un test ? Le BDD emprunte le format des « user stories » et du design orienté objet Le scénario est narratif et doit avoir un titre précis La section d’introduction présente: Qui est l’utilisateur principal Quel effet sera produit Quelle valeur sera retirée de la fonctionnalité Ensuite, chaque scénario décrit un cas d’utilisation en spécifiant: Une condition initiale Le ou les événements qui modifie le système L’état final attendu

Gherkin Lisible par le métier Produit un « Domain Specific Language » (DSL) Peut servir de documentation Sera utilisé par les tests automatisés Peu de mots-clés à connaître

La syntaxe Gherkin est un langage orienté ligne (comme Python) Chaque ligne exprime une étape du scénario (« step ») Il utilise l’indentation pour définir la structure La plupart des lignes commencent par un mot-clé Un commentaire est préfixé du dièse (#) Un scénario est rédigé dans l’une des 37 langues supportées

Exemple Feature: Serve coffee Coffee should not be served until paid for Coffee should not be served until the button has been pressed If there is no coffee left then money should be refunded

Scenario: Buy last coffee Given there are 1 coffees left in the machine And I have deposited 1$ When I press the coffee button Then I should be served a coffee

DémonstrationEn C#, et en utilisant SpecFlow