Ou comment passer le TDD (Test-Driven Development) sous stéroïdes. Ceci est l'introduction au BDD présentée lors de la Journée Agile 2016 à Namur.

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

2. 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)

3. 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 ?

4. 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.

5. 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

6. 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

7. 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 »

8. 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

9. 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

10. 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

11. 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

12. Démonstration
En C#, et en utilisant SpecFlow