BT

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

| par Jan Stenberg Suivre 34 Abonnés , traduit par Nicolas Frankel Suivre 7 Abonnés le 30 avr. 2014. Durée de lecture estimée: 2 minutes |

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

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Donnez-nous votre avis

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet
Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

M'envoyer un email pour toute réponse à l'un de mes messages dans ce sujet

Discuter

Se connecter à InfoQ pour interagir sur ce qui vous importe le plus.


Récupérer votre mot de passe

Follow

Suivre vos sujets et éditeurs favoris

Bref aperçu des points saillants de l'industrie et sur le site.

Like

More signal, less noise

Créez votre propre flux en choisissant les sujets que vous souhaitez lire et les éditeurs dont vous désirez suivre les nouvelles.

Notifications

Restez à jour

Paramétrez vos notifications et ne ratez pas le contenu qui vous importe

BT