Explorez les différences entre ‘Test Driven Development’ et ‘Behavior Driven Development’

En quoi consistent ces méthodes de test, quelle est la différence entre les deux et quelle est la méthode la plus efficace ?

Ces dernières décennies, le développement de logiciel a évolué d’une méthode ‘Cycle en V’ à une approche plutôt ‘Agile’. En effet, dans un monde en évolution rapide, il est essentiel de pouvoir délivrer de nouvelles fonctionnalités de manière rapide et flexible. Cette tendance vers l’évolution continue nécessite une méthode test qui soit aussi rapide, flexible et décisive, mais surtout efficace. Et c’est là où des termes comme TDD (‘Test Driven Development’) et BDD (‘Behavior Driven Development’) apparaissent souvent. Mais qu’est-ce qu’ils signifient exactement et quelle est la différence entre les deux ?

Le ‘Test Driven Development’ ou la programmation pilotée par le test est une méthode qui a vu le jour à la fin des années 90 et qui est attribuée à Kent Beck, un ‘extreme programmer’. Le principe très révolutionnaire à l’époque consiste dans les faits à d’abord écrire les tests avant même d’avoir écrit une ligne de code. L’idée est d’éviter les erreurs et les bugs dans le code en se focalisant sur les tests pendant le processus de développement. Plus précisément, le développeur va d’abord écrire le test pour un petit bout de fonctionnalité, il va par la suite lancer ce test pour vérifier qu’il échoue et ce n’est qu’après l’échec de ce test qu’il écrit le code suffisant qui permettra de faire passer le test. L’accent est purement mis sur l’exigence demandée et le code sera donc très simple et ciblé. Dans une phase suivante, le code sera remanié (‘refactored’) afin de s’assurer qu’il soit bien structuré et conforme au code existant. Cette méthode favorise un développement ciblé sur les exigences, évitant tout code superflu.

Le pouvoir du TDD vient du fait que les fonctionnalités sont divisées en petits bouts testables et pour chaque bout de fonctionnalité un ou plusieurs tests sont écrits. Ainsi le logiciel sera testé de manière systématique et continue, lors de la moindre modification. Cette méthode aide à immédiatement détecter les erreurs éventuelles tout au début du processus de développement, ce qui signifie un gain de temps et d’argent énorme, comme l’a démontré la courbe de Boehm.

Le ‘Behavior Driven Development’ ou la programmation pilotée par le comportement est née en réponse aux difficultés que Dan North a rencontrées lors de l’implémentation du TDD. Alors que le TDD se focalise sur l’exactitude du code lié à un petit bout de fonctionnalité et que le développeur travaille de manière indépendante, l’essence du BDD se base sur le comportement désiré du logiciel dans sa totalité et sur la collaboration étroite entre le développeur, le testeur et le responsable produit (les ‘3 amigos’). Le but essentiel du BDD c’est de combler le fossé de communication entre les parties prenantes à l’aide d’un langage commun, notamment la syntaxe Gherkin ‘Given-When-Then’ (Étant donné–Lorsque-Alors). Tout comme le TDD, la méthode BDD privilégie l’écriture des tests vis-à-vis du code. Ce processus comprend plusieurs phases, comme par exemple l’organisation d’une réunion ‘example mapping’ où l’on divise les user stories à l’aide de cette technique bien spécifique. Lors de cette session les 3 amigos se réunissent afin d’établir des exemples concrets qui permettent de vérifier la valeur de la user story et se mettre d’accord sur les critères d’acceptation. Dès qu’ils arrivent à un consensus, les scénarios se formalisent dans des fichiers de fonctionnalités (les ‘feature files’). Grâce à l’application du langage commun basé sur les mots clé ‘Given-When-Then’, il y a une compréhension partagée entre les différentes parties prenantes, les malentendus sont exclus au maximum dès le début du processus de développement, et enfin et surtout, les scénarios se transforment facilement en tests automatiques.

On pourrait donc conclure que le BDD s’axe sur le but supérieur, en partant du comportement désiré du logiciel dans sa totalité, porté et compris tant par le responsable produit, que le testeur et le développeur. Le TDD par contre se concentre sur le code individuel, mais peut en parallèle de la méthode BDD aider à améliorer la qualité du code en veillant à ce que chaque bout de fonctionnalité soit couvert par un ou plusieurs tests unitaires.