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