Différences TDD et BDD

Honnêtement, je ne vois pas la différence entre BDD et TDD. Je veux dire, les deux ne sont que des tests si ce qui est attendu se produit. J’ai vu des tests BDD qui sont si étoffés qu’ils comptent pratiquement comme des tests TDD, et j’ai vu des tests TDD qui sont tellement vagues qu’ils encadrent beaucoup de code. Disons que je suis assez convaincu que les deux sont mieux.

Voici une question amusante cependant. Où est-ce que je commence? Est-ce que je commence avec des tests BDD de haut niveau? Est-ce que je commence avec des tests TDD de bas niveau?

Honnêtement, je ne vois pas la différence entre BDD et TDD.

C’est parce qu’il n’y en a pas.

Je veux dire, les deux ne sont que des tests si ce qui est attendu se produit.

C’est faux. BDD et TDD n’ont absolument rien à voir avec les tests. Aucun. Nada. Rien. Zip *: français. Rien. Pas du tout.

Malheureusement, TDD a le mot “test” dans à peu près tout (pas seulement dans son nom, mais aussi dans le framework de test, le test unitaire, TestCase (la classe dont vous héritez normalement), FooTest (la classe qui contient vos tests), testBar (le modèle de nommage typique pour une méthode de test), plus beaucoup de terminologies liées aux tests telles que “assertion” et “vérification”) qui amènent certains à penser que cela a quelque chose à voir avec les tests. Ainsi, certaines personnes intelligentes ont dit: “Hé, changeons simplement le nom” pour supprimer tout risque de confusion.

Et c’est ce que BDD est. Il s’agit simplement de TDD avec toute terminologie liée aux tests remplacée par des terminologies liées à des comportements:

  • Test → Exemple
  • Assertion → Attente
  • assertshould
  • Unité → Comportement
  • Vérification → Spécification
  • … etc

BDD est juste TDD avec des mots différents. Si vous faites TDD, vous faites du BDD. La différence est que – à condition que vous croyiez au moins à la forme faible de l’hypothèse Sapir-Whorf – les différents mots facilitent la tâche.

BDD est du sharepoint vue des clients et se concentre sur le comportement attendu de l’ensemble du système.

TDD est du sharepoint vue des développeurs et se concentre sur la mise en œuvre d’une unité / classe / fonctionnalité. Il bénéficie entre autres d’une meilleure architecture (conception pour la testabilité, moins de couplage entre les modules).

Du sharepoint vue technique (comment écrire le “test”), ils sont similaires.

Je voudrais (d’un sharepoint vue agile ) commencer avec un bdd-userstory et l’implémenter en utilisant TDD.

D’après ce que j’ai recueilli sur Wikipedia, BDD inclut l’acceptation et le test d’assurance qualité qui ne peuvent être réalisés sans la participation des parties prenantes / utilisateurs. De plus, BDD utilise un langage naturel pour spécifier son test, tandis que TDD utilise généralement un langage de programmation. Il pourrait y avoir un certain chevauchement entre les deux mais je pense que ce n’est pas le flou mais le langage de BDD qui constitue la principale différence.

En ce qui concerne votre sharepoint départ, cela dépend vraiment de votre processus de développement, n’est-ce pas? Je suppose que si vous faites une parsing ascendante que vous allez écrire TDD en premier et une fois que vous aurez atteint un niveau supérieur, vous utiliserez BDD pour tester si ces fonctionnalités fonctionnent comme prévu.

Comme l’a noté k3b: la principale différence serait que le BDD est orienté vers le domaine des problèmes alors que le TDD est plus orienté vers le domaine des solutions.

Il suffit de copier la réponse de Matthew Flynn sur laquelle je suis plus d’accord que “TDD et BDD n’ont rien à voir avec les tests”:

Behavior Driven Development est une extension / révision de développement piloté par les tests. Son but est d’aider les personnes qui conçoivent le système (c’est-à-dire les développeurs) à identifier les tests appropriés à écrire, c’est-à-dire les tests qui reflètent le comportement souhaité par les parties prenantes. L’effet finit par être le même – développez le test puis développez le code / système qui réussit le test. Le BDD espère que les tests sont réellement utiles pour montrer que le système répond aux exigences.

METTRE À JOUR

Les unités de code (méthodes individuelles) peuvent être trop granulaires pour représenter le comportement représenté par les tests comportementaux, mais vous devez toujours les tester avec des tests unitaires pour garantir leur bon fonctionnement. Si c’est ce que vous entendez par “tests TDD”, alors oui, vous en avez toujours besoin.

Un article fantastique sur les différences entre TDD et BDD:

http://www.lostechies.com/blogs/sean_chambers/archive/2008/12/07/starting-with-bdd-vs-starting-with-tdd.aspx

Devrait vous donner tout ce que vous devez savoir, y compris les problèmes avec les deux, et des exemples.

BDD consiste à obtenir votre droit TDD. Il fournit “structure et diciplene” à votre TDD. Il vous aide à tester la bonne chose et à faire le bon test. Voici un petit article fantastique sur BDD et TDD,

http://codingcraft.wordpress.com/2011/11/12/bdd-get-your-tdd-right/

La terminologie est différente, mais dans mon travail, j’utilise TDD pour les détails de développement, principalement pour le test unitaire, et le BDD est de plus haut niveau, pour le client, l’assurance qualité ou l’homme sans technologie.

La principale différence est juste la formulation. BDD utilise un style plus verbeux pour pouvoir le lire presque comme une phrase.

Je pense que la plus grande consortingbution de BDD à TDD ou à toute autre approche consiste à intégrer des personnes non techniques (propriétaires de produits / clients) au processus de développement logiciel à tous les niveaux.

L’écriture de scénarios exécutables en langage naturel a presque comblé le fossé entre l’exigence et la livraison.

Les propriétaires de produits peuvent exécuter eux-mêmes les scénarios qu’il a écrits et tester avec différents jeux de données s’il souhaite contourner le comportement du code écrit par l’équipe de développement.

C’est incroyable! Le client est assis au centre et ne demande pas seulement ce qu’il veut vraiment, mais il vérifie et expérimente également les produits livrables.