Afin d’en occulter l’aspect technique, il a donc remplacé le mot « test » par celui de « behaviour » et ainsi rendu la rédaction des tests plus évidente et intuitive pour les développeurs.
Grâce à ce petit changement sémantique, le développeur n’écrit plus un test, il définit le comportement que doit avoir le code.
De plus, afin de rendre l’écriture des tests encore moins technique et toujours plus accessible et intuitive, il a également fait en sorte de permettre la définition de ce comportement non plus à l’aide d’un langage de programmation, mais à l’aide d’un langage naturel.
Grâce à cela, un vocabulaire commun entre le développeur et le métier peut être mis en place et le développeur n’est plus le seul à pouvoir lire, comprendre ou écrire un test.
Et c’est efficace, puisque 7 ans après la rédaction de cet article, le BDD a le vent en poupe actuellement.
Rien que dans l’univers PHP, le succès d’un outil tel que Behat qui permet la rédaction de test fonctionnel en BDD le démontre.
Pour autant, un test à la sauce BDD reste un test, et il est donc très possible de faire du BDD avec un outil de TDD.
En effet, un test à la sauce BDD fait techniquement exactement la même chose qu’un test à la sauce TDD puisqu’il vérifie le résultat que doit fournir un code en fonction des données qui lui sont fournies.
Ou exprimé autrement, le BDD étant essentiellement une évolution sémantique, la seule différence technique entre un test en BDD et un test en TDD est son formalisme.
Il est donc très possible pour un développeur d’écrire avec un outil de TDD bien conçu tel qu’atoum un test compréhensible par l’Humain.
<?php namespace vendor\project\tests\units; use atoum, vendor\project\helloWord as testedClass; class helloWorld extends atoum { function testSay() { $this ->given($helloWorld = new testedClass())->then->string($helloWorld->say())->isEqualTo('Hello World!') ; } }
Et voici le test équivalent rédigé à l’aide de PHPSpec, un outil de BDD :
<?php namespace spec\HelloWorld; use PHPSpec2\ObjectBehavior; class HelloWorld extends ObjectBehavior { function it_says_hello() { $this->say()->shouldReturn('Hello World!'); } }
Alors, faut-il mieux faire du TDD ou du BDD ?
Si vous avez compris ce qui précède, vous avez compris que cette question est stupide, puisque le TDD ou le BDD ne sont que les deux facettes d’une même pièce.
Alors, comment choisir entre un outil dédié au BDD et un outil dédié au TDD ?
Il n’y a pas de réponse absolue à cette question.
En effet, étant donné que chaque outil de test a ses propres forces, ses propres faiblesses et sa propre philosophie, le développeur choisira essentiellement en fonction de ses préférences personnelles.
Cependant, de mon point de vue, l’approche du BDD n’a que peu d’intérêt dans le cas de tests unitaires.
En effet, ce type de test est de très bas niveau et le code qu’il valide n’est qu’un pavé encastré dans la route qui conduit à la réalisation du besoin exprimé par le métier.
Il me semble donc inutile à un niveau aussi bas de disposer d’un outil de test permettant d’impliquer fortement le métier, puisque le code développé à l’aide de ces tests aura forcément une très forte composante technique très éloignée de ses préoccupations.
Un bon outil de test unitaire « traditionnel » est donc une option à mon sens parfaitement viable dans le cadre des tests unitaires, surtout s’il a été conçu de façon à être simple et intuitif.
À contrario, un outil de BDD tel que Behat me semble plus que recommandé dans le cas de tests fonctionnels. Ces derniers valident en effet un besoin métier et il est donc bénéfique pour le projet d’avoir à ce niveau une collaboration forte entre le développeur et le métier.
Ce n’est cependant que mon avis et de toute façon, que vous écriviez des tests en TDD ou en BDD n’a aucune importance, car comme je l’ai expliqué, c’est blanc bonnet et bonnet blanc.
L’important, c’est d’écrire des tests !
11 réactions
1 De Florian Klein - 29/04/2013, 16:16
La différence fondamentale entre BDD et TDD est à mon sens le fait qu'avec la BDD, tu commences a décrire des comportements attendus, pour *vérifier* plus tard que ton application est conforme à tes attentes. Les outils de BDD te *forcent* à penser en terme de business, de valeur ajoutée, de fonctionalités. La TDD, ou ses outils, te permettent juste de vérifier que ce que tu as codé est correctement codé. Alors oui, tu peux faire de la BDD avec de la TDD, en arretant de dire que tu *testes*, mais au contraire que tu *décris* des comportements. LA est toute la différence.
2 De mageekguy - 29/04/2013, 16:19
@Florian Klein : Je pense que tu n'as pas compris ce qu'est le TDD : le TDD, c'est ce que tu décris en parlant du BDD ;).
Du coup, je souris doucement.
CQFD.
3 De naholyr - 29/04/2013, 16:56
Grrr, relou le formatage des commentaires avec les sauts de ligne pas conservés… Bon ben désolé pour ceux qui tenteront de déchiffrer ça sans la mise en forme.
J'aime bien l'approche de mocha (un outil de tests très populaire pour JS) pour ça :
À supposer que "BDD" n'implique pas une technologie particulière (comme cucumber & co), je suis totalement d'accord.
C'est vrai qu'il n'y a techniquement aucune différence et que les deux peuvent être gérées par le même outil. Perso j'aime bien écrire mes "tests" avec un "style" BDD. Après tout il ne s'agit que du "comportement" d'une API, donc ça fait pour moi partie du même lot.
4 De sanpi - 29/04/2013, 17:25
TDD = { UTDD, BDD, … }
Simple non ?
- UTDD = unit test driven development (atoum) ;
- BDD = behaviour driven development (behat).
C’est très simple de savoir quand les utiliser : cela dépend de la personne qui écrit ou lit les tests. Un client est généralement en mesure de comprendre le français mais pas le PHP, à l’inverse d’un développeur.
5 De dePassage - 30/04/2013, 05:49
L'auteur Dan North que vous citez en début de post s'explique de lui-même sur l'objection que vous formulez:
http://dannorth.net/2012/05/31/bdd-...
et confirme ce qu'avance sanpi dans son commentaire:
"BDD is the same thing but for a broader audience"
cqfd
6 De mageekguy - 30/04/2013, 08:26
@dePassage : Je connais aussi cette article, et ce n'est de toute façon pas pour rien que j'insiste sur l'aspect métier dans mon billet.
Et encore une fois, il est possible d'impliquer le métier sans aucun problème avec un outil TDD, ce n'est pas une exclusivité du BDD.
CQFD.
7 De oaz - 30/04/2013, 08:57
Bien d'accord avec la similarité BDD/TDD. La seule différence réside dans la lisibilité.
J'avais écrit un billet dans ce sens il y a quelques temps : http://agilitateur.azeau.com/post/2...
8 De Florian Klein - 30/04/2013, 12:16
Tu pourrais continuer à écrire toute ta vie des applications en appliquant les principes de la TDD. Ton CI sera tout vert et tu seras content. Mais c'est pas parce que un CI est vert, que ton client l'est aussi (ici: heureux). Pourquoi ? Parce que tu as oublié de parler business avec lui, lorsque il fallait le faire. la BDD, c'est concilier communication l'et assurance que ton application se comporte comme VOULU. la TDD, c'est écrire des tests avant d'écrire le code.
Sauf si tu es très malin et que tu as un client technique (toi même par exemple), alors peut-etre qu'un outil de BDD est overkill parce que tu peux faire de la BDD avec les outils habituellement utilisés en TDD. Mais la BDD et la TDD, contrairement aux commentaires précédents, sont pas === un outil en particulier, mais à une manière de penser.
9 De mageekguy - 30/04/2013, 12:17
@Florian Klein : Le BDD n'est nullement différent du TDD, que ce soit techniquement ou fonctionnellement.
Il s'agit uniqument d'un renommage sémantique qui permet de rendre le test plus compréhensible à la fois pour le développeur et pour le métier (ce que je dis explicitement dans mon billet et que je ne renie aucunement).
Mais fondamentalement, le BDD est du TDD car dans un cas comme dans l'autre, fonctionnellement, la spécification représentée par les tests permet de définir et valider le comportement du code avant son écriture (à ce niveau, la seule différence réside dans le vocabulaire utilisée, plus technique dans le cas du TDD, plus généraliste et accessible dans le cas du BDD), et techniquement, les mêmes solutions sont utilisées.
Tu le dis toi-même, en plus, le BDD hérite (même si la notion d'héritage est très ténue dans ce cas puisque c'est un simple "rebranding") du TDD.
Mais peut être que si tu relis le commentaire de @naholyr, tu comprendra mieux ce que je veux dire…
J'ajoute que si tu développes, sans test ou avec et indépendamment de leur nature, sans te soucier des besoins de ton client, il est inutile de poursuivre ta carrière dans le développement ou tout autre métier, d'ailleurs.
Il n'y a pas besoin de faire du BDD pour intégrer les besoins du client dans ton développement : tu n'a pas le choix, tu dois forcément le faire, et ce n'est pas une méthode de test ou autre chose qui forcera un développeur à le faire.
Le BDD permet juste d'avoir un langage plus compréhensible par les deux parties.
10 De Florian Klein - 30/04/2013, 12:36
Tu peux rire doucement, ca n'empeche pas les faits.
Comme le résume si bien Dann North, "BDD becomes the communication across all of those stakeholders to create a single coherent vision and deliver to that". Ce que ne fait pas, même en riant, la TDD. CQFD.
Après, je suis entièrement d'accord que les processus cycliques de développement de la TDD s'appliquent a la BDD: Write the spec, make it fail -> write the code, make it pass. Red -> green. C'est pas parce ques couleurs sont les même, que le but est le même.
En fait, si ca s'applique si bien, c'est parce que la BDD *hérite* de la TDD.
11 De karl - 01/05/2013, 15:14
@mageekguy, @florian: On peut adopter la position que BDD et TDD sont toutes les deux des conventions pour aider au développement, avec un vocabulaire légèrement différent en fonction du public auquel il s'adresse.
Et les deux partent du principe où on crée une hypothèse de départ, que l'on remplit par la création subséquente du code. Pour l'instant, nous sommes tous sur les mêmes rails.
Une fois que l'on s'échappe de la méthode et que l'on passe au détail des tests proprement dit, je pense que c'est là que votre charge sémantique diffère entre vous deux. Je pense que Florian parle de Unit Testing utilisé en TDD. Il y a de nombreuses choses que l'on peut tester au niveau du code qui ne sont pas directement exposées dans les règles d'affaires (Business Rules) et qui pourraient être exprimées en effet en BDD, mais qui le seront rarement car trop complexes pour l'interlocuteur.
Je pense que le terme behavior choisi par Dan North prête également à confusion. Code Behavior != User Behavior. De nombreux exemples de BDD sont très orientés très haut niveau de règles d'affaires générales. "Paul en tant qu'utilisateur du service Whizzz peut acheter un billet de cinéma en euros." qui aura probablement des dizaines de *Unit* Tests afin de vérifier toutes les conditions.