BDD : Behavior Data Driven

La méthodologie que nous venons de présenter s’inscrit donc autour de l’approche BDD. BDD est une sorte d’extension du TDD que nous avons présenté dans le chapitre Tester en continu : tests unitaires, où l’implémentation se faisait par la validation progressive du test. L’idée cette fois-ci est de détailler en langage naturel la composition d’une fonctionnalité. On ne traite pas du comment on va l’implémenter, mais plutôt du pourquoi. En effet, le but de ces spécifications n’est pas d’expliquer comment les équipes vont réaliser techniquement une fonctionnalité par exemple. Comme le langage est proche du langage de tous les jours, c’est plutôt de décrire le comportement attendu de celle-ci.

C’est ce qui rend ce langage intéressant. Le client n’est pas noyé par des détails techniques qu’il ne maîtrise peut-être pas et la discussion reste volontairement axée vers un dialogue compris par toutes les parties. Les éventuelles incompréhensions peuvent donc être gommées.

Lorsque l’équipe de réalisation participe aussi à cette phase initiale, cela peut mettre l’ensemble des intervenants d’accord sur ce qui doit être développé et quel doit être le comportement de la fonctionnalité dans un contexte...

Pour consulter la suite, découvrez le livre suivant :
couv_EPDEVOPIC.png
60-signet.svg
En version papier
20-ecran_lettre.svg
En version numérique
41-logo_abonnement.svg
En illimité avec l'abonnement ENI
130-boutique.svg
Sur la boutique officielle ENI
Précédent
Introduction
Suivant
Écrire les user stories : langage Gherkin