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!

Voici un nouvel exemple d'utilisation de Powershell, histoire de peut-être vous donner envie de pratiquer ce shell bien utile. Dans mes tests, j'ai souvent un processus qui tourne en boucle, d'ailleurs grâce un script posté dans un billet précédent. Ce processus génère un fichier de log à chaque fois, ce qui me fait des dizaines de milliers de fichiers. Pour éviter de remplir le disque dur, je voudrais garder uniquement les fichiers de log qui présentent un intérêt, par exemple ceux qui contiennent le mot ERROR. C'est facile en PowerShell, avec un peu de pratique on peut le faire directement sur la ligne de commande :

» Lire la suite!

Je dois souvent surveiller des processus, typiquement pour voir comment évolue leur consommation de mémoire, le nombre de handles, de threads etc. Pour cela, perfmon.exe est un outil bien approprié, et permet d'afficher beaucoup de compteurs de performance Windows, et également de les sauvegarder dans un fichier journal :

» 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!

Quand nous avons mis en place Scrum en 2005, notre but était de développer plus rapidement et plus facilement de nouveaux produits, entre autres objectifs. Au fil du temps nous avons découvert que même si Scrum fonctionne parfaitement bien, nous n'avons pas réellement développé plus rapidement. L'hyper-productivité mentionnée par certains ne nous a jamais rendu visite ! Néanmoins je reste convaincu qu'il y a encore beaucoup de possibilités de mieux développer les nouveaux produits, et surtout de gagner du temps. Je ne suis pas obsédé par une "productivité" bien difficile à mesurer, mais par contre je déteste les gaspillages de temps : débogages interminables, faire/défaire/refaire une histoire utilisateur mal comprise, séjours chez les clients pour résoudre des problèmes mystérieux. la liste est bien longue.

Une clé pour un développement plus facile de nouveaux produits est probablement d'accompagner la pratique de Scrum par le développement d'une nouvelle culture d'entreprise favorisant l'amélioration continue.

» Lire la suite!

Voici un autre billet initialement publié sur notre blog interne, et que je republie en externe.

Pour montrer comment j'utilise PowerShell (le shell remplaçant DOS, et développé par Microsoft sur .NET), voici un petit exemple de lancement de programme en boucle. C'est le script que j'utilise en ce moment pour essayer de reproduire un gel d'un de nos logiciels qui est constaté chez un client.

[Contexte : ce gel arrive 2 à 3 fois par an, et uniquement chez ce client - la fréquence d'apparition est donc très faible, c'est pourquoi je suis conduit à faire des centaines de milliers d'exécution pour essayer de le reproduire - et c'est pourquoi l'automatisation via PowerShell est très utile]

Ce script maintient en exécution simultanée x instances d'un programme donné, jusqu'à ce qu'on parvienne à un nombre donné de lancements.

» Lire la suite!

Voici un exemple de billet publié sur notre blog interne. Mon but est d'alimenter le blog interne avec du contenu utile pour mes collègues, tout en me servant de ce blog pour remplacer les cahiers où je notais autrefois les trucs et astuces que j'apprenais. Le contexte : j'apprends régulièrement un peu de PowerShell, le nouveau shell de Microsoft, car cela me rend service dans mon travail, et je pense qu'il serait utile aussi à mes collègues. Le billet ci-dessous présente donc un exemple tout simple d'accès au journal d'événement Windows.

» Lire la suite!

Une conséquence inattendue mais bénéfique de notre démarche de caddying est que nous avons maintenant un blog interne utilisable par tous les employés du site. Il utilise le moteur Pebble qui a été assez simple à mettre en place (de l'ordre d'une journée de travail). L'idée est venue d'un de nos caddies qui souhaitait pouvoir publier sur son activité de caddy (et permettre à ses joueurs de publier leurs propres billets, par exemple pour des retours d'expérience). En tant que "Meta-caddy", j'ai encouragé cette initiative qui va bien dans la direction que j'imaginais il y a quelques mois (voir ce billet sur la mise en place du caddying) :

- les caddies seront encouragés à publier des retours d'expérience sur leur action, ou encore sur leur domaine de prédilection... L'idée étant que leur action devrait servir à générer de la connaissance (thème que j'explorais dans ce précédent billet).

En effet notre démarche de caddying doit contribuer à notre démarche actuelle de nous doter de nouveaux outils et moyens de favoriser l'amélioration continue et l'apprentissage.

» Lire la suite!