BDD - TDD à la manière BDD
Dans TDD, le terme «tests d'acceptation» est trompeur. Les tests d'acceptation représentent en fait le comportement attendu du système. Dans les pratiques Agile, l'accent est mis sur la collaboration de toute l'équipe et les interactions avec le client et les autres parties prenantes. Cela a conduit à la nécessité d'utiliser des termes facilement compréhensibles par toutes les personnes impliquées dans le projet.
TDD vous fait réfléchir au nécessaire Behavior et donc le terme `` comportement '' est plus utile que le terme ‘Test’. BDD est un développement piloté par les tests avec un vocabulaire axé sur le comportement et non sur les tests.
Pour reprendre les mots de Dan North, «J'ai trouvé le passage de la pensée dans les tests à la réflexion dans le comportement si profond que j'ai commencé à parler de TDD comme BDD, ou Behavior Driven Development.» TDD se concentre sur la façon dont quelque chose fonctionnera, BDD se concentre sur la raison pour laquelle nous le construisons.
BDD répond aux questions suivantes souvent rencontrées par les développeurs -
| Question | Répondre |
|---|---|
| Où commencer? | dehors dans |
| Que tester? | Histoires d'utilisateurs |
| Que ne pas tester? | rien d'autre |
Ces réponses aboutissent au cadre de l'histoire comme suit -
Story Framework
Comme un [Role]
Je voudrais [Feature]
pour que [Benefit]
Cela signifie: `` Quand un Feature est exécuté, le résultat Benefit est à la personne jouant le Role.'
BDD répond en outre aux questions suivantes -
| Question | Répondre |
|---|---|
| Combien de tester en une seule fois? | très peu focalisé |
| Comment appeler leurs tests? | modèle de phrase |
| Comment comprendre pourquoi un test échoue | Documentation |
Ces réponses donnent le cadre d'exemple comme suit -
Example Framework
Given un contexte initial,
When un événement se produit,
Then garantir certains résultats.
Cela signifie: `` En commençant par le contexte initial, lorsqu'un événement particulier se produit, nous savons quels should be».
Ainsi, l'exemple montre le comportement attendu du système. Les exemples sont utilisés pour illustrer différents scénarios du système.
Histoire et scénarios
Considérons l'illustration suivante de Dan North sur un système ATM.
Récit
As a client,
I want retirer de l'argent à un guichet automatique,
so that Je n'ai pas à faire la queue à la banque.
Scénarios
Il existe deux scénarios possibles pour cette histoire.
Scenario 1 - Le compte est créditeur
Given le compte est créditeur
And la carte est valide
And le distributeur contient de l'argent
When le client demande de l'argent
Then s'assurer que le compte est débité
And s'assurer que l'argent est distribué
And s'assurer que la carte est retournée
Scenario 2 - Le compte est à découvert au-delà de la limite de découvert
Given le compte est à découvert
And la carte est valide
When le client demande de l'argent
Then s'assurer qu'un message de rejet est affiché
And s'assurer que de l'argent n'est pas distribué
And s'assurer que la carte est retournée
L'événement est le même dans les deux scénarios, mais le contexte est différent. Par conséquent, les résultats sont différents.
Cycle de développement
Le cycle de développement pour BDD est un outside-in approche.
Step 1- Rédigez un exemple de valeur commerciale (externe) de haut niveau (en utilisant Cucumber ou RSpec / Capybara) qui devient rouge. (RSpec produit un framework BDD en langage Ruby)
Step 2 - Ecrivez un exemple RSpec de niveau inférieur (à l'intérieur) pour la première étape de mise en œuvre qui passe au rouge.
Step 3 - Implémentez le code minimum pour passer cet exemple de niveau inférieur, voyez-le passer au vert.
Step 4 - Écrivez l'exemple de RSpec de niveau inférieur suivant en poussant vers l'étape 1 qui passe au rouge.
Step 5 - Répétez les étapes 3 et 4 jusqu'à ce que l'exemple de haut niveau de l'étape 1 devienne vert.
Note - Les points suivants doivent être gardés à l'esprit -
Red/green state est un statut d'autorisation.
Lorsque vos tests de bas niveau sont verts, vous avez l'autorisation d'écrire de nouveaux exemples ou de refactoriser l'implémentation existante. Vous ne devez pas, dans le cadre du refactoring, ajouter de nouvelles fonctionnalités / flexibilité.
Lorsque vos tests de bas niveau sont rouges, vous avez l'autorisation d'écrire ou de modifier le code d'implémentation uniquement pour faire passer les tests existants au vert. Vous devez résister à l'envie d'écrire le code pour réussir votre prochain test, qui n'existe pas, ou mettre en œuvre des fonctionnalités que vous pensez peut-être bonnes (le client ne l'aurait pas demandé).