Behaviour Driven Development : cela vaut-il la peine pour vous ?
Le Behaviour Driven Development (BDD), dans votre cas personnel, est-ce que ça ferait une différence ? Ça dépend de votre contexte, et cet article est là pour vous aider à répondre à cette question.
Si vous voulez uniquement et directement savoir si le BDD apporterait un plus pour vous, vous pouvez vous contenter du paragraphe Est-ce que ça vaut le coup pour moi ? et vous limiter à lui. Si vous voulez un peu plus approfondir, alors le reste de cet article vous explique pourquoi.
Préambule
Le BDD n’est maintenant plus tout jeune puisqu’il a été introduit en 2006 par Dan North avec l’article Introducing BDD suite aux travaux sur JBehave attaqués en 2003 menés notamment avec Liz Keogh. Malgré tout, il est toujours autant d’actualité dans les débats comme pour de nombreuses autres pratiques tout aussi anciennes d’ailleurs (TDD, Extreme Programming, intégration continue, agilité…). Il est notamment d’actualité pour moi car l’une des équipes avec lesquelles je travaille en ce moment souhaite investir dans cette pratique. Or, ma première expérience d’inclusion du BDD dans une équipe remonte maintenant à 10 ans en arrière et j’ai pu observer au fil du temps que, mal utilisé, ou utilisé pour les mauvaises raisons, cette pratique peut devenir un irritant sans résoudre le problème initial. Alors revenons avant tout très rapidement sur les bases.
Ton histoire de BDD, c’est pas un peu surfait ?
Le BDD. On en entend parler. Beaucoup. Et on ne voit pas forcément la différence avec le TDD. Ou même, plus simplement la différence avec le fait d’avoir des tests bien écrits :
Héhé oui, vous ne m’aurez pas ! Behaviour, ça veut dire comportement. Lorsque l’on fait des tests automatisés de bonne qualité, ne doit-on pas déjà être en train de tester du comportement ? N’en feriez-vous pas des caisses pour quelque chose qui existe déjà par hasard et qu’on appelle le TDD ?
C’est une question légitime. Mais comme souvent, pour apprendre, il faut d’abord désapprendre.
Laissez tomber les tests !
Si vous voulez réellement comprendre le BDD, vous devez d’abord oublier ce que vous croyez savoir à son propos. Je vous propose donc d’oublier les tests (juste le temps de l’article hein). Oubliez aussi les outils : Cucumber, Behave, Behat… on s’en fiche pour l’instant. Faites le vide avec moi… C’est bon ? Alors étudions maintenant si cela vaudrait la peine pour vous de creuser le BDD.
Est-ce que ça vaut le coup pour moi ?
Voici 6 questions qui pourraient vous aider à forger votre propre opinion, dans le contexte d’un de vos projets passés ou de votre projet actuel :
- Dans votre équipe, sur plus d’une user story sur trois, vient-on vous rapporter des comportements non conformes lors de la validation avant mise en prod, ou même après mise en production ?
- Alors que vous avez déjà bien avancé sur le développement d’une user story, cela vous arrive-t-il régulièrement de faire marche arrière sur des développements car vous aviez compris de travers certains besoins ?
- Lorsque vous commencez une user story, mettez-vous beaucoup de temps avant de vous lancer dans l’implémentation à cause du comportement attendu difficile et long à comprendre ?
- Est-ce que certaines stories exprimées dans vos sprints s’avèrent incohérentes au moment de les commencer ? Par exemple, alors que vous commencez la réalisation, vous vous apercevez qu’on vous a demandé de tracer 7 droites rouges qui se croisent au même point tout en étant perpendiculaires entre elles, avec de l’encre incolore pour certaines et verte pour d’autres (cf. The Expert)
- Les spécifications fonctionnelles sont-elles inexistantes ? Ou si vous en avez, vous arrive-t-il qu’elles ne soient pas à jour par rapport au fonctionnement réel du code ?
- Y a-t-il des frictions récurrentes entre les personnes aux sprint plannings (ou autres ateliers équivalents de priorisation/engagement) aux moments des discussions sur le livrable attendu ?
Si vous avez répondu non à toutes ces questions, alors de mon expérience, ce n’est pas la peine de vous fatiguer, vous allez probablement perdre plus de temps qu’autre chose. Car tout ce que vous obtiendrez ce sont des tests plus difficiles à maintenir que ceux que vous avez déjà. Dans votre contexte, soit il y a une simplicité suffisante dans le comportement fonctionnel des applications sur lesquelles vous contribuez, soit vous avez trouvé une autre manière d’organiser la communication que le BDD.
Si en revanche vous avez répondu oui à l’une des questions listées ci-dessus, alors vous pouvez vous rendre la vie plus belle grâce au BDD. Ce que vous pourrez constater dans toutes ces questions, c’est qu’il est à chaque fois question d’information, de compréhension et donc de la qualité de la communication dans votre équipe.
La communication avant tout
Je ne vais pas vous donner la définition du BDD car déjà beaucoup se sont prêtés à l’exercice, sachant qu’il n’existe pas de « vraie » définition, comme l’explique Dan North dans son article BDD By Example (d’ailleurs j’attends toujours avec impatience qu’il remplisse le fameux site évoqué…). Alors si vous devez retenir quelque chose, c’est que le BDD est une super approche pour communiquer efficacement autour du comportement d’un logiciel. La communication dans une équipe est la base de tout. Car tout commence par comprendre le besoin que l’on cherche à satisfaire. Et le concept de BDD ne cherche à répondre à rien d’autre qu’à ça, même dans sa toute première évocation alors qu’on n’y avait encore pas évoqué les 3 amigos qui ont été popularisés en 2009 par George Diwindie. Si vous n’avez pas ce besoin, ou que vous avez déjà répondu à ce besoin d’une autre manière, alors vous devriez vous tourner vers d’autres outils (notamment si vous comptiez vous intéresser au BDD uniquement pour avoir des tests de non-régression…).
Bon, donc, le BDD est très efficace pour faciliter la communication, OK. Mais pourquoi ?
Pourquoi ça marche ?
Le BDD repose sur le constat que nous sommes des êtres faits pour comprendre des successions d’événements, par exemple pour le déroulement d’une journée, pour les histoires ou pour les scénarios. Même dans les disciplines constituées de lois et de règles, comme les sciences ou le droit, la compréhension ne commence-t-elle pas par des illustrations et des exemples ? Personnellement, pas sûr que j’aurais réussi comprendre le théorème de Pythagore sans avoir jamais vu un triangle rectangle… C’est seulement ensuite qu’on généralise. Alors, si l’on cherche à comprendre un besoin, et en particulier lorsqu’il est complexe, si l’on veut pouvoir le remettre en question, il vaut mieux mille fois choisir les exemples illustrant les règles et laisser chacun retrouver la règle par lui-même. C’est le principe de la spécification par l’exemple souvent associé au BDD et c’est la garantie que chacun aura vraiment bien compris la règle.
Conclusion
Faire ou ne pas faire de BDD n’a pas vraiment de lien avec la couverture de votre code par vos tests, et cette pratique est différente du TDD parce que le BDD est avant tout un outil de communication et de compréhension (très bonne réponse de la part de Dan North à Robert C. Martin qui prétend le contraire, dans cet article BDD is like TDD if…). Il permet de retirer l’ambiguïté et d’éprouver les fonctionnalités demandées. Il permet de tirer parti de l’intelligence collective. En quelque sorte, vous pouvez le considérer comme le design émergent de la spécification. Et à la fin, la problématique à laquelle s’attaque le BDD, c’est sans doute, comme le dit Dan North dans BDD is not About Testing, « d’écrire du logiciel qui compte vraiment, pour les personnes dont vous impactez la vie » (“Writing software that matters, for people whose lives you touch”).
Alors, si vous avez constaté qu’un des symptômes de mauvaise communication évoqués plus haut dans le petit questionnaire était avéré dans votre équipe, vous pouvez commencer à creuser le sujet, vous aurez beaucoup à y gagner.
Pour toute autre motivation non directement liée à l’un de ces symptômes, il existe sans aucun doute une meilleure solution à votre problème que le BDD. Et pratiquer le BDD pour les mauvaises raisons amène souvent à de mauvais résultats, voire potentiellement au dégoût complet de certains membres de l’équipe.
Si vous décidez de vous lancer, sachez que la mise en place du BDD est subtile et pleine de pièges, donnant sans doute une des pratiques les plus difficiles à maîtriser dans l’ingénierie logicielle. Alors, vraiment, allez-y, mais surtout prenez régulièrement du recul sur vos pratiques pour les améliorer en continu !
Du contenu suivra cet article pour vous donner de la matière à propos de ces pièges et des manières dont vous pourriez vous organiser en équipe, organiser votre code, structurer et tester vos step definitions pour qu’ils demeurent maintenables… N’hésitez pas à guetter le blog pour ça !
Merci et à bientôt !