L'Agilitateur - Le Behaviour Driven Development ou l'art d'écrire des tests que tout le monde comprend - CommentairesCréation de logiciels : de l'agilité à l'artisanat2021-10-09T15:11:31+02:00urn:md5:7668924f626a6543fa389f1b4e47e529DotclearLe Behaviour Driven Development ou l'art d'écrire des tests que tout le monde comprend - ehsavoieurn:md5:060f518f1525602d31bca5be3fa7dfba2009-01-15T10:24:20+01:002009-01-15T10:24:20+01:00ehsavoie<p>Je pense que le BDD permet l'utilisation d'un langage unique pour les tests quelque soit leur 'niveau':<br />
On peut utiliser le BDD pour rendre le TDD intuitif => on est au niveau tests unitaires.<br />
On peut aussi décrire les fonctions ou comportements du système avec la MOA = > on est au niveau des exigences fonctionnelles et des tests d'acceptabilité.<br />
L'approche JBehave 2.0 est à mon humble avis exactement celle là en prenant des histoires d'utilisateur en format plein texte comme entrée. Il manque sûrement un éditeur sexy (quoique les wikis ...).<br />
Mes 2 centimes :o)</p>Le Behaviour Driven Development ou l'art d'écrire des tests que tout le monde comprend - Oazurn:md5:25ddd69915d986457340ff624f76debf2008-11-10T17:58:25+01:002008-11-10T17:58:25+01:00Oaz<p>Oui, le principal défaut de mon exemple est de n'être qu'un exemple !!!<br />Les tests développeur issus des histoires utilisateur sont importants. Je n'ai jamais dit l'inverse. <a hreflang="fr" href="https://agilitateur.azeau.com/post/2007/08/16/TDD-sur-page-blanche" rel="ugc nofollow">Bien au contraire</a>.</p>
<p>Mais posons la question autrement :</p>
<ul><li>dans un développement piloté par les tests, peut-on se contenter de tests développeur issu d'histoires utilisateur ?</li>
<li>Si on ne peut pas s'en contenter, pourquoi ne pourrait-on pas appliquer le BDD sur les tests développeur non issus d'histoires utilisateur ?</li>
</ul>Le Behaviour Driven Development ou l'art d'écrire des tests que tout le monde comprend - claudeurn:md5:cf29c87d835410b5d6be50c7df80e9882008-11-10T14:15:45+01:002008-11-10T14:15:45+01:00claude<p>Le BDD est une technique orientée comportement dont le sujet peut être le système ou un de ses composants. Les articles de Dan North abondent de références aux user stories et aux tests d'acceptation, le sujet y est donc le système (logiciel). Dans ton exemple aussi...<br />
Sur l'aspect méthode de conception, on en reparle.</p>Le Behaviour Driven Development ou l'art d'écrire des tests que tout le monde comprend - oazurn:md5:28c0cbc4268c32a3ace8e533b3a6898d2008-11-10T10:36:50+01:002008-11-10T10:37:41+01:00oaz<p>@claude,<br />Pour moi, "l'art de rendre exécutables des tests fonctionnels exprimés par un client", c'est plutôt ce que l'on appele le TDR (Test Driven Requirements) avec des outils tels que <a hreflang="en" href="http://fitnesse.org/" rel="ugc nofollow">Fitnesse</a> ou <a hreflang="en" href="http://www.greenpeppersoftware.com/" rel="ugc nofollow">Greenpepper</a>.</p>
<p>Le BDD, même si cela permet de se rapprocher -dans certains cas- d'une vision plus fonctionnelle, ça reste au niveau de la conception. J'admets que mon exemple avec un test qui porte sur du code métier peut prêter à confusion. Le BDD s'applique aussi bien à du code métier qu'à du code plus technique. Quand je dis "des tests que tout le monde comprend", le "tout le monde" signifie éventuellement des gens du métier (qui peuvent ainsi lire le test si celui-ci est un test de code métier) mais il signifie en premier lieu les autres développeurs pour qui l'intention du test est bien plus visible.</p>
<p>Sur la liste de discussion xp-france, il y avait eu un embryon de débat "évolution de TDD : BDD, TDR...". Je vois que <a hreflang="en" href="http://blog.valtech.fr/wordpress/2008/06/28/behavior-driven-development-vs-test-driven-requirements/" rel="ugc nofollow">Eric Lefèvre en a également parlé sur le blog Valtech</a>. A mon avis, envisager le BDD uniquement comme une approche plus fonctionnelle des tests développeur est une erreur de compréhension de ce qu'est le BDD. TDR et BDD interviennent à des niveaux différents même si on observe une convergence lorsqu'il s'agit d'exprimer des tests fonctionnels.</p>Le Behaviour Driven Development ou l'art d'écrire des tests que tout le monde comprend - claudeurn:md5:f981a546d62472bcad36d88ebf3c73cd2008-11-09T20:46:11+01:002008-11-09T20:46:11+01:00claude<p>L'art d'écrire des tests que tout le monde comprend... Ca serait pas mieux de dire l'art de rendre exécutables des tests fonctionnels (exprimés par un client) ?</p>