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
