Dans un précédent article, nous avons vu l’importance du dialogue pour espérer réussir à mettre en pratique la méthode BDD.
Ici, je vais tenter d’illustrer une autre problématique : comment passer des cas de tests aux scénarios BDD ?
J’ai été confronté à cette réflexion dans le cadre d’un atelier de Revue BDD pour présenter le premier besoin d’une nouvelle application.
Pour commencer voici quelques liens afin de vulgariser STUB et Méthode d’extension.
Après cet éclaircissement, je peux vous expliquer pourquoi il m’est arrivé de devoir mettre en place un STUB sur une méthode d’extension lors de développement sur du code legacy.
Dans ce fameux code, une méthode d’extension fut développée, mais celle-ci faisait appel à une ressource externe. Ma première réaction était de me dire de ne plus passer par cette méthode mais plutôt par un objet non static qui implémenterai un interface serait plus facilement “Stubable”. En effet, je peux aisément l’injecter dans la classe qui en a besoin et ainsi définir pour mes tests une autre implémentation de cette interface. Cependant un grand nombre de références à cette extension fut remonté. Afin de ne pas modifier tout le code qui n’était pas protégé par des tests, j’ai préféré chercher un moyen de “Stuber” la méthode d’extension.
Nous sommes tous concernés par la qualité logicielle, et donc, de nos tests unitaires. Nous sommes souvent confrontés à un problème : Comment tester qu’une méthode lève bien telle exception ?
