Catégorie: BDD

Avant de passer au compte-rendu du dojo d'aujourd'hui, voici un nouvel éclairage sur l'articulation entre TDD et BDD, que j'emprunte à ce billet Behavior Driven Development with NBehave (trouvé grâce à cet autre billet Bien Tester une application Asp.net MVC sur le BDD par Guillaume Saint Etienne).

Je pense que dans les dojos précédents nous avons bien compris et bien pratiqué le cycle RED/GREEN/REFACTOR du TDD :

Nous voulons maintenant comprendre comment cela s'articule avec le BDD (partant du principe que nous sommes convaincus que cela vaut le coup de s'intéresser au BDD).

Je trouve que le schéma ci-dessous de Behavior Driven Development with NBehave illustre assez bien la manière de procéder, du BDD vers le TDD :

» Lire la suite!

Dans le 18e coding dojo du Club Agile Rhône Alpes, ce 5 janvier dernier, j'avais pris un exemple réel issu de nos plans de tests, et basé sur les courbes de calibration, un concept très utilisé en chimie (et donc dans nos applications). Demain, dans la 20ème session, nous poursuivrons sur cet exemple. Comme pas mal de jours ont passé, ce billet est destiné à nous rafraîchir la mémoire sur la question, à moi le premier !

» Lire la suite!

Pour démarrer la discussion sur la rédaction de spécifications exécutables l'autre soir au CARA, j'avais pris l'exemple de la réalisation d'un logiciel de comptage de calories. L'exemple n'est pas gratuit : je trouve que la plupart des logiciels de ce genre ont une interface utilisateur très influencée par l'implémentation avec une base de données, et pas très influencée par les besoins utilisateurs. Pardonnez l'expression, mais ce genre de logiciel "pue la base de données", alors que la base de donnée n'a que peu de valeur pour l'utilisateur - c'est juste un choix d'implémentation bien pratique pour les développeurs.

Par conséquent, il me semble que travailler sur un tel logiciel est intéressant pour apprendre le BDD, car justement nous aimerions éviter de "polluer" les scénarios par des concepts purement techniques comme des questions de base de données. Le challenge est donc de parvenir à exprimer les scénarios avec des mots d'utilisateur et pas du jargon informatique.

Dans ce billet je vais détailler mon point de départ et illustrer les premières leçons que j'ai tirées des discussions. Bien sûr cela reste un exemple "jouet" mais je parviendrai peut-être à en faire une application complète dans quelque temps.

Je suis également passé à la rédaction de scénarios en français, ce qui est possible en Cucumber (tapez la commande cucumber -i18n fr pour avoir les équivalences).

Mon point de départ était la fonctionnalité suivante :

» Lire la suite!

La réunion du CARA sur la rédaction de spécifications exécutables grâce au BDD (Behavior Driven Development) a été très intense. Merci aux nombreux participants pour cette soirée stimulante et aux camarades du CARA pour l'organisation ! J'ai le sentiment que tout le monde a pu gagner une compréhension plus concrète du BDD, et a pu appréhender l'aspect collaboratif de la rédaction de scénarios.

Les discussions ont certainement dérivé de l'objectif initial qui était d'explorer différentes manière d'écrire des spécifications exécutables, mais elles n'en ont pas moins été très intéressantes. Il y a eu trop d'échanges pour tout retracer dans un seul billet, donc ici je vais me concentrer sur l'un des aspects : pourquoi s'intéresser au BDD ?

» Lire la suite!

Pour illustrer un cas (extrême) de la flexibilité du format Given/When/Then que je mentionnais précédemment, voici un exemple GreenPepper (à partir de la version 2.6 GreenPepper supporte l'écriture de scénarios à la Cucumber - merci Emmanuel pour l'information).

GreenPepper est tellement flexible que les mots-clés Given/When/Then ne sont même pas obligatoires. Ainsi on peut écrire des scénarios comme celui-ci :

» Lire la suite!

Le dojo du 5 janvier à Grenoble concernait l'exploration de l'articulation entre TDD et BDD, sur la base d'un exemple que j'avais proposé. L'exemple s'appuie sur la problématique de la calibration des instruments scientifiques, problématique que nous devons souvent traiter dans nos logiciels. L'exemple est donc tout à fait concret et réaliste, implique des calculs assez rapides à programmer (comme la régression linéaire) qu'il serait néanmoins judicieux de traiter en TDD. De plus il comporte des spécifications trompeusement simples (source de diverses incompréhensions entre développeurs et utilisateurs) que le BDD pourrait certainement traiter. Le BDD devrait d'ailleurs permettre d'élaborer un modèle métier satisfaisant. C'est pourquoi cet exemple me paraît bien approprié et j'espère que nous le poursuivrons dans de futures séances.

Durant le dojo il y a eu des questions sur la manière dont j'avais rédigé les spécifications en Cucumber, ce qui est normal car le format Given/When/Then offre beaucoup de flexibilité. Rien ne vous force à utiliser When par exemple, ou à limiter les tests à des sections Then. En ce qui me concerne, j'ai l'habitude quand je code de faire les calculs au moment où l'on demande les résultats (ce qui est possible quand il y a peu de données, et évite de gérer des questions de cohérence données/résultats). Donc je n'éprouve pas trop le besoin de mentionner un déclenchement avec un When par exemple. Mais c'est probablement un cas où mon style et mes habitudes de programmation influencent directement sur la rédaction des spécifications exécutables, ce qui n'est guère souhaitable - dans le BDD nous souhaitons justement éviter de polluer les spécifications par des concepts très liés à l'implémentation, pour rester focalisés sur le modèle métier.

» Lire la suite!

Pour conclure mon exploration des moyens de pratiquer le BDD en .NET, il me restait à examiner Cuke4Nuke, l'équivalent de Cuke4Duke de Java. C'est chose faite, et ce billet montre comment installer tout ce qu'il faut pour arriver à faire tourner l'exemple du jeu du pendu qui m'a servi dans les billets précédents.

» Lire la suite!

Je poursuis mon exploration des différentes possiblités de faire du Behavior Driven Development sur plate-forme .NET. Après avoir examiné l'approche NBehave, je vais voir comment utiliser plus directement Cucumber (une des principales références en BDD, avec une communauté très active). Cucumber étant programmé en Ruby, on peut donc utiliser IronRuby, l'implémentation de Ruby pour .NET. Dans ce billet je décris l'installation de IronRuby, celle de Cucumber sous IronRuby, et je montrerai l'exécution de mon exemple prédécent dans ce nouvel environnement. Faire tourner Cucumber sous IronRuby a été un peu laborieux pour moi, donc j'essaierai très prochainement une autre approche, celle de Cuke4Nuke - Cucumber for .NET qui promet d'être plus directe.

» Lire la suite!

Un lecteur m'ayant indiqué qu'une nouvelle version de NBehave (0.4.5) était disponible depuis une semaine, j'ai repris l'exemple du jeu du pendu pour voir comment on écrivait maintenant les tests et le code de "pontage" (la façon dont j'ai procédé jusqu'à présent étant obsolète). L'expérience est assez satisfaisante, on procède comme avec Cucumber. J'ai donc écrit mes scenarios (purement textuels) puis écrit une classe C# pour faire le pont avec le code de "production", ma classe Game. Ici j'ai réutilisé la classe résultant de mes essais précédents pour aller vite, il aurait été préférable de se laisser guider par les tests pour découvrir petit à petit cette classe - c'est ce que vous conseille si vous voulez tenter l'expérience. Ci-dessous je présente les scénarios, puis la classe de pontage.

» Lire la suite!

Dans un billet précédent j'avais expliqué les bases de NBehave, outil qui permet de faire du BDD (Behavior Driven Development) en .NET. Je vais maintenant montrer un exemple plus complet, développé à l'occasion des Coding Dojos du Club Agile Rhône-Alpes juste avant la pause estivale. Durant les dojos, Emmanuel Etasse nous avait proposé de développer un jeu du pendu, et avait joué le rôle de Product Owner. Nous avions identifié 3 users stories (gérer une lettre, gérer deux lettres successives, gérer la fin de jeu), chacune avec plusieurs scénarios. Dans ce billet je vais montrer le code correspondant, et expliquer pourquoi, après cette expérimentation, l'approche NBehave ne me convient pas trop, et pourquoi je suis beaucoup plus intéressé par une approche de type Cucumber sur IronRuby.

» Lire la suite!

Dans un billet précédent j'avais expliqué les bases de NBehave, outil qui permet de faire du BDD (Behavior Driven Development) en .NET. Je vais maintenant montrer un exemple plus complet, développé a l'occasion des Coding Dojos du Club Agile Rhône-Alpes juste avant la pause estivale. Durant les dojos, Emmanuel Etasse nous avait proposé de développer un jeu du pendu, et avait joué le rôle de Product Owner. Nous avions identifié 3 users stories (gérer une lettre, gérer deux lettres successives, gérer la fin de jeu), chacune avec plusieurs scénarios. Dans ce billet je vais montrer le code correspondant, et expliquer pourquoi, apres cette expérimentation, l'approche NBehave ne me convient pas trop, et pourquoi je suis beaucoup plus intéressé par une approche de type Cucumber sur IronRuby.

» Lire la suite!

Je fais mes premiers pas en BDD - le Behavior Driven Development (développement dirigé par les comportements). A ce stade j'ai du mal à voir s'il s'agit d'une simple variante du TDD (développement dirigé par les tests), ou bien s'il s'agit de quelque chose de vraiment différent et novateur. Le BDD semble permettre de faire des tests à plus haut niveau que les tests unitaires, directement au niveau des histoires d'utilisateurs (user story), et produit un rapport d'exécution de test compréhensible par un non informaticien, contrairement aux tests unitaires usuels. Certains trouvent cela très utile pour démontrer à leurs clients qu'ils font bien les tests, et indiquer précisément quels tests ils font, pour d'autres c'est simplement un moyen d'implémenter des spécifications exécutables et avoir une meilleure couverture de code.

Pour se faire une idée plus précise de cette nouvelle technique, rien ne vaut une expérimentation concrète, je vais donc participer demain à une séance de BDD avec mes camarades du Coding Dojo du CARA. Voici comment j'ai préparé mon environnement Visual Studio 2008 pour pouvoir faire du BDD, dans une configuration minimaliste pour démarrer.

» Lire la suite!