Quelles sont les principales différences entre TDD et BDD? [fermé]

Le développement piloté par les tests fait fureur dans la communauté .NET depuis quelques années. Récemment, j'ai entendu des grognements dans la communauté ALT.NET à propos de BDD. Qu'Est-ce que c'est? Qu'est-ce qui le différencie du TDD?

Je comprends que BDD concerne davantage les spécifications que les tests . Il est lié à Domain Driven Design (vous n'aimez pas ces * acronymes DD?).

Il est lié à une certaine manière d'écrire des user stories, y compris des tests de haut niveau. Un exemple de Tom ten Thij :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(Dans son article, Tom poursuit en exécutant directement cette spécification de test dans Ruby.)

Le pape de BDD est Dan North . Vous trouverez une excellente introduction dans son article Présentation de BDD .

Vous trouverez une comparaison entre BDD et TDD dans cette vidéo . Aussi un avis sur BDD comme "TDD bien fait" par Jeremy D. Miller

Mise à jour du 25 mars 2013

La vidéo ci-dessus est manquante depuis un certain temps. En voici un récent par Llewellyn Falco, BDD vs TDD (expliqué) . Je trouve son explication claire et pertinente.

Pour moi, la principale différence entre BDD et TDD est la concentration et la formulation. Et les mots sont importants pour communiquer votre intention.

TDD se concentre sur les tests. Et comme dans le «vieux monde de la cascade», les tests viennent après la mise en œuvre, alors cet état d'esprit conduit à une mauvaise compréhension et un mauvais comportement.

BDD se concentre sur le comportement et les spécifications, et ainsi les esprits en cascade sont distraits. Ainsi, BDD est plus facilement compris comme une pratique de conception et non comme une pratique de test.

Il semble y avoir deux types de BDD.

Le premier est le style original dont parle Dan North et qui a provoqué la création des frameworks de style xBehave. Pour moi, ce style est principalement applicable aux tests d'acceptation ou aux spécifications par rapport aux objets du domaine.

Le deuxième style est ce que Dave Astels a popularisé et qui, pour moi, est une nouvelle forme de TDD qui présente de sérieux avantages. Il se concentre sur le comportement plutôt que sur les tests et aussi sur les petites classes de test, en essayant d'arriver au point où vous avez essentiellement une ligne par méthode de spécification (test). Ce style convient à tous les niveaux de test et peut être fait en utilisant n'importe quel framework de test unitaire existant, bien que les nouveaux frameworks (style xSpec) aident à se concentrer sur le comportement plutôt que sur les tests.

Il existe également un groupe BDD que vous pourriez trouver utile:

http://groups.google.com/group/behaviordrivendevelopment/

Le développement piloté par les tests est une méthodologie de développement logiciel axée sur les tests, ce qui signifie qu'il faut écrire du code de test avant d'écrire le code réel qui sera testé. Dans les mots de Kent Beck:

Le style ici est d'écrire quelques lignes de code, puis un test qui devrait s'exécuter, ou encore mieux, d'écrire un test qui ne s'exécutera pas, puis d'écrire le code qui le fera fonctionner.

Après avoir compris comment écrire un petit morceau de code, maintenant, au lieu de simplement coder, nous voulons obtenir des commentaires immédiats et pratiquer "coder un peu, tester un peu, coder un peu, tester un peu". Nous écrivons donc immédiatement un test pour cela.

Ainsi, TDD est une méthodologie technique de bas niveau que les programmeurs utilisent pour produire un code propre qui fonctionne.

Le développement axé sur le comportement est une méthodologie qui a été créée sur la base du TDD, mais qui a évolué vers un processus qui ne concerne pas uniquement les programmeurs et les testeurs, mais qui traite plutôt avec toute l'équipe et toutes les parties prenantes importantes, techniques et non techniques. BDD est parti de quelques questions simples auxquelles TDD ne répond pas bien: combien de tests dois-je passer? Que dois-je tester et que ne dois-je pas tester? Lequel des tests que j'écris sera en fait important pour l'entreprise ou pour la qualité globale du produit, et lesquels ne sont que ma sur-ingénierie?

Comme vous pouvez le constater, ces questions nécessitent une collaboration entre la technologie et les entreprises. Les parties prenantes commerciales et les experts du domaine peuvent souvent dire aux ingénieurs quels types de tests semblent utiles, mais uniquement si les tests sont des tests de haut niveau traitant d'importants aspects commerciaux. BDD appelle ces tests de type professionnel des «exemples», comme dans «Donne-moi un exemple de la manière dont cette fonctionnalité doit se comporter correctement», et réserve le mot «test» aux vérifications techniques de bas niveau telles que la validation des données ou les tests d'intégrations d'API. La partie importante est que tandis que tests ne peuvent être créés que par des programmeurs et des testeurs, les exemples peuvent être collectés et analysés par toute l'équipe de livraison - par les concepteurs, les analystes, etc.

En une phrase, l'une des meilleures définitions de BDD que j'ai trouvée jusqu'à présent est que BDD consiste à «avoir des conversations avec des experts du domaine et à utiliser des exemples pour acquérir une compréhension commune du comportement souhaité et découvrir des inconnues». La partie découverte est très importante. Au fur et à mesure que l'équipe de livraison recueille de plus en plus d'exemples, elle commence à comprendre de plus en plus le domaine de l'entreprise et réduit ainsi son incertitude quant à certains aspects du produit qu'elle doit traiter. À mesure que l'incertitude diminue, la créativité et l'autonomie de l'équipe de livraison augmentent. Par exemple, ils peuvent maintenant commencer à suggérer leurs propres exemples que les utilisateurs professionnels ne pensaient pas possibles en raison de leur manque d'expertise technologique.

Maintenant, avoir des conversations avec les experts en affaires et dans le domaine sonne bien, mais nous savons tous comment cela se termine souvent dans la pratique. J'ai commencé mon parcours avec la technologie en tant que programmeur. En tant que programmeurs, on nous apprend à écrire du code - algorithmes, modèles de conception, abstractions. Ou, si vous êtes designer, on vous apprend à concevoir—Organisez les informations et créez de belles interfaces. Mais lorsque nous obtenons nos emplois d'entrée de gamme, nos employeurs s'attendent à ce que nous «apportions de la valeur aux clients». Et parmi ces clients peut être, par exemple ... une banque. Mais je ne savais presque rien sur les services bancaires, sauf comment réduire efficacement le solde de mon compte. Il faudrait donc que je traduise en quelque sorte ce que l'on attend de moi en code ... Je devrais construire un pont entre la banque et mon expertise technique si je veux offrir une valeur. BDD m'aide à construire un tel pont sur une base stable de communication fluide entre l'équipe de livraison et les experts du domaine.

Apprendre encore plus

Si vous voulez en savoir plus sur BDD, j'ai écrit un livre sur le sujet. "Rédaction de spécifications exceptionnelles" explore l'art de l'analyse des exigences et vous aidera à apprendre à créer un excellent processus BDD et à utiliser des exemples au cœur de ce processus. Le livre parle du langage omniprésent, de la collecte d'exemples et de la création de spécifications dites exécutables (tests automatisés) à partir des exemples, des techniques qui aident les équipes BDD à fournir des logiciels de qualité dans les délais et le budget.

Si vous êtes intéressé par l'achat de «Rédaction de spécifications exceptionnelles », vous pouvez économiser 39% avec le code promotionnel 39nicieja2 :)

J'ai un peu expérimenté l'approche BDD et ma conclusion prématurée est que BDD est bien adapté à la mise en œuvre de cas d'utilisation, mais pas sur les détails sous-jacents. Le TDD reste à ce niveau.

Le BDD est également utilisé comme outil de communication. Le but est de rédiger des spécifications exécutables compréhensibles par les experts du domaine.

Il me semble que BDD est un champ d'application plus large. Cela implique presque l'utilisation du TDD, que BDD est la méthodologie englobante qui rassemble les informations et les exigences pour utiliser, entre autres, les pratiques TDD pour assurer une rétroaction rapide.

Avec mes dernières connaissances en BDD par rapport à TDD, BDD se concentre sur la spécification de ce qui va se passer ensuite, tandis que TDD se concentre sur la configuration d'un ensemble de conditions et ensuite sur la sortie.

Le développement axé sur le comportement semble se concentrer davantage sur l'interaction et la communication entre les développeurs et également entre les développeurs et les testeurs.

L'article Wikipédia a une explication:

Développement axé sur le comportement

Mais je ne pratique pas le BDD moi-même.

Considérez que le principal avantage du TDD est la conception. Il devrait être appelé Test Driven Design. BDD est un sous-ensemble de TDD, appelez-le Behavior Driven Design.

Considérons maintenant une implémentation populaire de TDD - Unit Testing. Les unités dans les tests unitaires sont généralement un bit de logique qui est la plus petite unité de travail que vous pouvez effectuer.

Lorsque vous assemblez ces unités de manière fonctionnelle pour décrire le comportement souhaité aux machines, vous devez comprendre le comportement que vous décrivez à la machine. La conception axée sur le comportement se concentre sur la vérification de la compréhension par les implémenteurs des cas d'utilisation / exigences / quoi que ce soit et vérifie la mise en œuvre de chaque fonctionnalité. BDD et TDD en général ont pour objectif important d'éclairer la conception et le second objectif de vérifier l'exactitude de la mise en œuvre, en particulier lorsqu'elle change. BDD bien fait implique biz et dev (et qa), tandis que les tests unitaires (éventuellement considérés à tort comme TDD plutôt que comme un type de TDD) sont généralement effectués dans le silo de développement.

J'ajouterais que les tests BDD servent d'exigences de vie.

BDD est en grande partie TDD bien fait. Cependant, BDD offre une valeur supplémentaire. Voici un lien à ce sujet:

BDD est plus que «TDD bien fait»

Il n'y a aucune différence entre TDD et BDD. sauf que vous pouvez mieux lire vos tests et que vous pouvez les utiliser comme exigences. Si vous écrivez vos exigences avec les mêmes mots que vous écrivez des tests BDD, alors vous pouvez venir de votre client avec certains de vos tests définis prêts à écrire du code.

Différence entre le développement piloté par les tests (TDD) et le développement piloté par le comportement (BDD)

• BDD se concentre sur l'aspect comportemental du système plutôt que sur l'
  aspect de mise en œuvre du système sur lequel TDD se concentre.

• BDD donne une compréhension plus claire de ce que le système doit faire
  du point de vue du développeur et du client. TDD
  donne seulement au développeur une compréhension de ce que le système doit faire.

• BDD permet à la fois au développeur et au client de travailler ensemble sur l'analyse des besoins contenue dans le code source du système.

En bref, il existe une différence majeure entre TDD et BDD Dans TDD, nous nous concentrons principalement sur les données de test Dans BDD, notre objectif principal est le comportement du projet afin que toute personne non-programmeur puisse comprendre la ligne de code au nom du titre de cette méthode

Voici un aperçu rapide:

• TDD est juste le processus de test du code avant de l'écrire!

• DDD est le processus d'information sur le domaine avant chaque cycle de toucher du code!

• BDD est une implémentation de TDD qui apporte certains aspects de DDD!