lundi 6 février 2012

Petite synthèse sur le Behaviour Driven Development

Voici une petite synthèse de mon crû sur le BDD

  • les noms des méthodes de test doivent être des phrases en langage métier
  • les noms des méthodes de test doivent commencer par doit ou doivent (ou Should)
  • si une classe fait plus d'une chose, il faut introduire d'autres classes pour faire une partie du travail: injection de dépendance
  • si un test échoue après changement du code, soit:
    • un bug a été introduit: corriger le bug
    • le comportement attendu reste pertinent mais s'est déplacé: déplacer le test en le modifiant éventuellement
    • le comportement attendu n'est plus pertinent: supprimer le test
  • ne pas parler en terme de test mais en terme de comportement
  • rechercher la chose la plus importante (en terme de valeur métier / business value) que le système ne fait pas encore et la réaliser
  • le comportement d'une Story est un critère de validation
  • les story sont décrites comme suit:
   En tant que {X}: le bénéficiaire
   Je veux {Y}: la fonctionnalité (feature)
   Afin que {Z} : le bénéfice
  • Les stories sont détaillées sous forme de scénarios:
   Étant donné/ Given : le contexte initial
   Quand / Lorsque / When: un unique événement se produit
   Alors / Then: on vérifie qu'on obtient les résultats attendus
  • Les Given et les Then peuvent être multiples en utilisant Et / And
  • Le When est unique
  • Ces 3 parties de scénario sont codables et doivent être capitalisées / réutilisées
  • Dans les premières itérations, on y utilise des bouchons / mock qui seront supprimés au fur et à mesure

Ceci permet de répondre aux questions usuelles

  • qu'est-ce qu'un test ? une phrase décrivant le prochain prochain comportement qui vous intéresse
  • combien de tests dois-je faire ? cf. point précédent, juste pour vérifier la phrase du point précédent
  • que faire quand un test échoue ? appliquer la procédure vue plus haut

Introduction au Behaviour Driven Developement

Traduction de l'article de Dan North: http://dannorth.net/introducing-bdd... paru pour la première fois dans Better Software Magazine en mars 2006 et publié ici avec son aimable autorisation.

J'avais un problème. Quand on utilise ou qu'on enseigne les pratiques agiles telles que le développement dirigé par les tests (TDD) sur des projets dans différents environnements, on rencontre toujours la même confusion et les mêmes difficultés de compréhension. Les programmeurs veulent savoir par où commencer, ce qu'il faut tester et ce qu'il ne faut pas tester, combien de tests doivent être exécutés en une fois, ce qui lance leurs tests et comment comprendre pourquoi un test échoue.

Plus on va profondément dans TDD, plus on a l'impression que le processus d'apprentissage est moins un processus d'amélioration progressive de sa maîtrise qu'une suite de tâtonnement et d'essais/erreurs. On arrive plus fréquemment à se dire : "si seulement quelqu'un m'avait dit ça avant" que "Eureka, une porte s'est ouverte". D'où la décision qu'il doit être possible de présenter le TDD d'une façon qui va directement aux bonnes choses et évite les écueils.

Une réponse est le Behaviour Driven Development (BDD). Il a émergé des pratiques agiles établies et est conçu pour les rendre plus accessibles et efficaces pour les équipes peu aguerries à la livraison de code agile. Au fil du temps, BDD a grandi pour englober une vision plus large de l'analyse agile et du test d'acceptation (de recette) automatisé.

Lire la suite...