[ASEGrenoble] Demo BDD

[Rémy Sanlaville]

Bonjour à tous,

Suite à la session Démo BDD lors de l'open space animé par nos amis de Kelkoo,
je souhaite faire partager quelques idées/réflexions pour essayer d'améliorer nos pratiques.

Tout d'abord, je tenais à les remercier pour nous avoir montré ce qu'ils ont mis en place
ce qui nous permet de travailler sur du concret.

Voilà donc quelques points d'amélioration/de réflexions que je proposerai :

• Une des grandes difficultés et d'arriver à écrire les spécifications exécutables au
  bon niveau d'abstraction. Souvent nous avons tendance à les écrire avec trop de détails
  techniques. Ceci est finalement assez normal  (pour les développeurs) car c'est ce qu'on nous
  a appris et ce que nous faisons quotidiennement pour nos développements. Néanmoins,
  ce n'est pas le bon niveau d'abstraction car même si on rajoute des termes métiers
  on reste à décrire le "comment" du besoin, i.e. qu'on décrit par quel moyen on répond au besoin (le "quoi").
  
  Le bon niveau d’abstraction est à mon avis de se placer au niveau du quoi qui porte la sémantique
  de ce qui est attendu indépendamment de la solution que nous utilisons pour y répondre (le comment).
  Cela veut dire que si on change la façon de répondre au besoin sans changer le comportement alors
  les spécifications exécutables doivent toujours passer sinon ils ont une dépendance avec l'implantation.
  
  Nous pouvons donc imaginer de mettre en place un garde fou en créant une implantation bouchon différente
  qui permettrait de s'assurer que nos spécifications exécutables ne dépendent pas de l'implantation.
  
  Une des contraintes qu'on peut se poser et de n'utiliser que des termes métiers pour d'écrire les spécifications
  exécutables et de bannir les termes d'implantation (à part ceux qui font partie du métier dans certains cas).
  Par exemple, plutôt que d'indiquer que la fonctionnalité doit retourner un fichier CSV, il vaut mieux indiquer que
  la fonctionnalité doit retourner des données ...(correspondant au métier).
  
  
• Généralement, nous avons trop tendance à vouloir tout décrire dans les spécifications exécutables. Par expérience
  de ce que j'ai pu lire et voir, il vaut mieux s'astreindre au minimum et éviter de prendre les spécifications exécutables
  comme des batteries de tests qui permettent de vérifier tous les cas possibles. Par exemple, les cas aux limites,
  doivent être gérés à un autre endroit (tests unitaires...). Par contre, cela n'empêche pas d'en parler lors des discussions
  avec les différents acteurs du projet (1re étape du cycle ATDD). Pour moi, un des rôles des spécifications exécutables,
  est d'améliorer la transmission entre le PO et l'équipe de développement de ce qu'il faut faire. C'est d'ailleurs pour cela
  que la spécification par les exemples est préconisée afin d'améliorer la transmission d'information.
  
  
• Comme l'a souligné Laurent Bossavit, lorsque nous voyons de la duplication dans la description des spécifications
  exécutables, cela peut s'apparenter à un smell. Il y a sans doute tout intérêt à faire du refactoring et de la mutualisation
  qui peut aider à faire ressortir le comportement souhaité. Les aspects liés à l'implantation devront se retrouver au niveau
  de la fixture (le code qui fait le lien entre la spécification exécutable et le code source de l'application) ou dans le code source.
  
  On peut d'ailleurs reprendre la question de Laurent Bossavit autour des personas lors de mon intervention. On pourrait
  envisager de définir des utilisateurs types (personas) qui font références à un contexte spécifique qu'il n'est pas besoin
  de re-décrire dans la spécification exécutables lorsqu'on les mentionne. Ce contexte se retrouvera au niveau de la fixture.
  
  
• Lors de mon étude, j'avais trouvé plusieurs articles intéressants sur la maintenabilité des features et du code correspondant
  avec le nombre grandissant de User Stories et des fonctionnalités (il y a sans doute eu d'autres articles très intéressants depuis,
  mais je n'ai plus eu l'occasion de refaire de la veille sur cet aspect-là).
  
  L'article de Dale H. Emery est particulièrement intéressant sur ce sujet. Il montre bien comment, en différentes étapes, il a
  réussi à passer des spécifications exécutables difficilement compréhensible et maintenable (car lié à l'implantation) a des
  spécifications exécutables qui décrivent le comportement via une sorte de DSL métier.
  Writing Maintainable Automated Acceptance Tests, Dale H. Emery, 23 novembre 2009
  
  Anatomy of a good acceptance test, Gojko Adzic, 16 juin 2010
  Writing Maintainable Acceptance Tests, Lance Walton, 4 mars 2010
  How to Structure a Scalable And Maintainable Acceptance Test Suite, Andreas Ebbert-Karroum, 20 juillet 2010
  Acceptance Test Design Principles, Jeff Langr and Tim Ottinger, 27 juillet 2010
  Writing Maintainable Automated Acceptance Tests, Robert C. Martin, 7 décembre 2009
  

Rémy