BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Le Behavior-Driven Development est l'échange, pas l'outillage

Le Behavior-Driven Development est l'échange, pas l'outillage

Le principe même du Behavior-Driven Development (BDD) est la converstation, pas l'outillage, a récemment dit Liz Koegh dans une présentation sur 10 ans de BDD à une conférence Cucumber. Liz, coach agile indépendante et contributrice à JBehave, croit que nous avons commis quelques grosses erreurs pendant nos années de pratique du BDD, mais est plutôt excitée à propos de notre compréhension actuelle et de certaines évolutions qui ont eu lieu ces dernières années.

En 2003, Dan North fut le premier à avoir l'idée du BDD en le définissant un peu comme le TDD, mais en utilisant le mot "devrait" à la place de "test" pour décrire comment le système devrait se comporter. Dan a alors introduit le BDD de manière formelle en 2006 après avoir découvert que discuter du comportement, en particulier des exemples, était plus fructueux que discuter des tests.

Liz a commis une erreur au départ en tentant de remplacer le mot "devrait" par "doit" pour se rapprocher du contrat, et beaucoup ont été d'accord, mais Dan a mis en lumière que "devrait" est préférable pour encourager les questions et l'échange.

La communauté utilisatrice du BDD a commis une autre erreur : certains ont proclamé qu'ils faisaient du BDD, mais sans aucun échange et ont parlé de tests BDD alors que l'objectif était de s'éloigner du mot test afin de solliciter les parties prenantes et les experts du domaine pour des exemples de comportement ou de scénarios. Liz insiste sur le besoin de revenir à l'échange. Elle a découvert que la concentration sur l'automatisation des tests ralentit les gens en leur faisant écrire trop de scénarios et que le recentrage sur l'outillage au détriment de l'échange - le message étant de s'éloigner de l'outillage - rend le BDD inopérant sauf si l'on dispose des échanges pour explorer le comportement du système.

Un nouveau concept que Liz trouve tout particulièrement intéressant pour l'estimation de la complexité est Cynefin. Ce dernier se concentre sur les scénarios qui comportent une grande part d'incertitude pour le métier, et utilise le BDD dans ce périmètre pour en découvrir les résultats.

Liz finit sa présentation avec l'objectif principal du BDD :

Le BDD est l'écriture de logiciel utile (en utilisant des exemples !)

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT