15
janvier
2010
Spécifications exécutables, illustration de la flexibilité avec GreenPepper
janvier
2010
Un article de Bruno Orsier
Pour illustrer un cas (extrême) de la flexibilité du format Given/When/Then que je mentionnais précédemment, voici un exemple GreenPepper (à partir de la version 2.6 GreenPepper supporte l’écriture de scénarios à la Cucumber – merci Emmanuel pour l’information).
GreenPepper est tellement flexible que les mots-clés Given/When/Then ne sont même pas obligatoires. Ainsi on peut écrire des scénarios comme celui-ci :
Voici le résultat de l’exécution :
Au début l’absence totale des mots-clés m’a un peu dérouté. Mais à la réflexion c’est la même logique qui me conduit à ne pas utiliser de When dans mes scénarios !
Et vous, qu’en pensez-vous ? Est-ce que ce scénario vous paraît facilement compréhensible ?
4 Commentaires + Ajouter un commentaire
Commentaires récents
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Rétrospectives, la directive première
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
- dans Des tableaux pour l’intégration d’un équipier dans une équipe Scrum
Salut Vincent, j’apprécie ta distinction « quoi/comment » – cela me permet de mettre des mots précis sur des éléments du débat qui se produit chaque fois que j’essaie d’introduire le BDD ! Je suis moi-même convaincu qu’il faut passer le maximum d’effort sur le « quoi ».
Bruno
Salut Bruno,
Comme tu le mentionnes, GreenPepper te laisse beaucoup de latitude dans l’écriture de tes scénarios. Tu peux utiliser la forme Given/When/Then si elle te convient, comme tu peux adopter un style plus libre (que je préfère).
Pour moi la grande valeur des scénarios est dans leur écriture en premier pour piloter le développement d’une feature. Tu vois dans l’exemple que le scénario décrit ce qui est possible en utilisant le système plutôt que comment c’est possible (clics de boutons, de liens, etc). Les détails du comment sont saisis dans l’infrastructure de test.
Un défaut que je constate souvent dans les scénarios BDD que tu peux trouver sur le net, c’est qu’ils mélangent le « quoi » et « comment » ce qui les rend fragiles. Pour ne pas tomber dans ce piège, la fixture qui répond au scénario que tu présente est en fait très simple à écrire, elle devrait déléguer simplement à une infrastructure de test qui sait comment effectuer un retrait ou un dépot. Si ton infrastructure de test pilote le système par son interface utilisateur (ton scénario est alors un test système), elle utilise par exemple une librairie comme WebDriver pour piloter ton navigateur internet.
— Vincent
Je suis bien d’accord avec toi, souvent les exemples sont du type login ou variante de calculette, ce qui ne rend pas service au BDD car laisse penser que ca ne fonctionne que pour des applis jouets… De mon côté, je suis toujours en phase d’apprentissage donc ne peux pas te répondre sur le coût en cas de scénarios non triviaux…
Bruno
Oui complètement, par contre l’implémentation est elle aisé ?
).
Il est vrai que l’utilisation de ce genre d’outil semble prometteuse dans un projet, je commençais à m’intéresser au TDR et à l’outil Fitnesse (d’ailleurs la frontière entre TDR et BDD n’est pas toujours évidente …), mais il reste à savoir le coût de développement des features pour des scénarios non triviaux, la balance est un cas vraiment simple à tester (un peu comme la calculette