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 !