janvier
2010
Un article de Bruno Orsier
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.
Ces questions rejoignent mes propres interrogations, car je trouve encore difficile, face à une feuille blanche, de me lancer dans l’écriture de spécifications. Il serait de plus souhaitable, sur un exemple donné, de comparer diverses manières d’utiliser le format Given/When/Then, pour déterminer ce qui est le plus clair, pour voir ce qui permet d’arriver à une meilleure collaboration et compréhension entre plusieurs personnes, et pour voir comment s’élabore un langage commun au sujet d’une application. C’est pourquoi nous allons utiliser la prochaine réunion du CARA, ce lundi 18 janvier (de 18h45 à 21h) pour faire un atelier concret sur la question.
Si le sujet vous intéresse, venez apprendre avec nous ! Il n’y aura pas de programmation a priori, simplement du travail sur papier ou tableau. Pas de présentation théorique non plus ! Nous démarrerons la séance en montrant des exemples concrets de scénarios pour ceux qui ne sont pas familiers avec la syntaxe.
A titre d’illustration de mon propos sur Given/When/Then et l’absence de When, voici les scénarios Cucumber que nous avons utilisés le 5 janvier. Le 18 janvier j’apporterai un autre exemple sur une application plus « grand public », un logiciel de comptage de calories – sujet intéressant pour ceux qui viennent de prendre de bonnes résolutions !
1 Commentaire + Ajouter un commentaire
Commentaires récents
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Rétrospectives, la directive première
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
[…] small »; var topsy_order = « count,retweet,badge »; var topsy_url = « http://blog.developpez.com/bruno-orsier/p8521/bdd/ce-18-janvier-session-du-cara-sur-la-red/ »; Add Topsy Retweet […]