Relation entre BDD et TDD


30

Quelle est la relation entre BDD et TDD?

D'après ce que j'ai compris, BDD ajoute deux choses principales par rapport à TDD: la dénomination des tests (assurer / devrait) et les tests d'acceptation. Dois-je suivre TDD pendant le développement par BDD? Si oui, mes tests unitaires TDD doivent-ils être nommés dans le même style assurer / doit?


1
BDD est un ensemble de TDD (Unitests) bien documentés
DD

Quelqu'un souhaite-t-il ajouter une réponse du camp de conception axée sur le comportement ? De mon point de vue, ces réponses concernent toutes les premières itérations de BDD. Les applications réussies de BDD de nos jours sont souvent plus proches de la conception et peuvent même omettre complètement les tests automatisés, le cas échéant.
Paul Hicks

La différence entre BDD et TDD est comme la différence entre Macroéconomie et Microéconomie. BDD = acquérir une compréhension des exigences à l'aide d'exemples et peut éventuellement être utilisé pour effectuer des tests de macros automatisés. (agilenoir.biz/en/am-i-behavioral-or-not), TDD = écriture de micro tests pour piloter le codage en écriture. Le podcast Agile Thoughts couvre également ces différences: agilenoir.biz/en/agilethoughts/test-automation-pyramid-series
Lance Kind

Réponses:


37

BDD ajoute un cycle autour du cycle TDD.

Donc, vous commencez avec un comportement et laissez cela conduire vos tests, puis laissez les tests conduire le développement. Idéalement, BDD est soumis à une sorte de test d'acceptation, mais ce n'est pas nécessaire à 100%. Tant que vous avez défini le comportement attendu, vous êtes d'accord.

Supposons donc que vous écrivez une page de connexion.

Commencez par le chemin heureux:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Cette syntaxe Given-And-When-And-Then-And est courante dans le développement axé sur le comportement. L'un des avantages est qu'il peut être lu (et, avec une formation, écrit) par des non-développeurs - c'est-à-dire que vos parties prenantes peuvent afficher la liste des comportements que vous avez définis pour la réussite d'une tâche et voir si elle correspond à leurs attentes bien avant de lancer un produit incomplet.

Il existe un langage de script, appelé Gherkin, qui ressemble beaucoup à ce qui précède et vous permet d'écrire du code de test derrière les clauses de ces comportements. Vous devez rechercher un traducteur basé sur Gherkin pour votre cadre de développement habituel. Cela sort du cadre de cette réponse.

Quoi qu'il en soit, revenons au comportement. Votre application actuelle ne le fait pas encore (si c'est le cas, pourquoi quelqu'un demande-t-il une modification?), Vous échouez donc à ce test, que vous utilisiez un lanceur de test ou que vous testiez simplement manuellement.

Alors maintenant, il est temps de passer au cycle TDD pour fournir cette fonctionnalité.

Que vous écriviez BDD ou non, vos tests doivent être nommés selon une syntaxe commune. L'une des plus courantes est la syntaxe «devrait» que vous avez décrite.

Écrivez un test: ShouldAcceptValidDetails. Passez par le cycle Red-Green-Refactor jusqu'à ce que vous en soyez satisfait. Passons-nous maintenant le test de comportement? Sinon, écrivez un autre test: ShouldRedirectToUserDefaultPage. Red-Green-Refactor jusqu'à ce que vous soyez heureux. Laver, rincer, répéter jusqu'à ce que vous remplissiez les critères énoncés dans le comportement.

Et puis nous passons au comportement suivant.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Maintenant, vous ne devriez pas avoir anticipé cela pour passer votre comportement précédent. Vous devez échouer ce test à ce stade. Revenez donc à votre cycle TDD.

Et ainsi de suite jusqu'à ce que vous ayez votre page.

Je recommande vivement The Rspec Book pour en savoir plus sur BDD et TDD, même si vous n'êtes pas un développeur Ruby.


Pouvez-vous simplement mettre des commentaires? Je ne comprends toujours pas ...
Honey

4

Ma compréhension de cela:

  • BDD a commencé comme un rebranding de TDD pour clarifier l'accent sur le comportement.
  • Il offre un support plus formel (DSL et outillage) pour se concentrer sur le comportement et les spécifications exécutables.
  • BDD peut désormais être considéré comme un surensemble de TDD. Il a grandi au fil du temps pour englober davantage le côté élicitation des exigences, mais le côté processus de développement en fait toujours partie intégrante.

Donc pour aborder le TDD fait la bonne partie de BDD. BDD a commencé comme un changement de langue de TDD pour rendre l'intention du processus claire. L'article d'introduction de Dan North sur BDD explique pourquoi se concentrer sur le mot comportement plutôt que sur test est utile - il aide à confirmer que vous ne construisez pas seulement le bon logiciel, vous construisez également le bon logiciel. Cela faisait toujours partie d'une bonne approche TDD, mais Dan l'a codifié un peu en BDD.


Ce que je pense que BDD rend un peu plus explicite que TDD, ou du moins formalise et prend en charge les outils, est cette approche à deux cycles / double boucle / zoom avant zoom arrière / extérieur. Vous décrivez d'abord le comportement attendu de la fonction (la boucle extérieure), puis effectuez un zoom avant sur la boucle intérieure pour gérer les spécifications de bas niveau.

Doubleloop TDD Sur http://www.metesreau.com/ncraft-workshop/

Gherkin, associé à des outils tels que Cucumber et SpecFlow, permet d'écrire ces spécifications de fonctionnalités de haut niveau, puis de les lier au code qui exécute le code de l'application. Je dirais que c'est là que BDD peut «se sentir» différent de TDD, mais il fait toujours la même chose, juste avec un support d'outil supplémentaire et une DSL. Un peu plus proche du TDD «traditionnel» utilise des outils comme rspec, nspec, spock. Celles-ci ressemblent un peu plus au même processus que vous suivriez en TDD «traditionnel» mais avec un langage plus axé sur le comportement.

Dans BDD in Action de John Ferguson Smart (fortement recommandé), il plaide pour une approche en double boucle, commençant par quelque chose comme jBehave au niveau des spécifications exécutables au niveau externe, puis passant à un outil comme Spock pour les spécifications de bas niveau.


BDD rapproche le concept de piloté par les tests des parties prenantes de l'entreprise. Gherkin est conçu pour être lisible par l'entreprise, et l'idée de «documentation évolutive», c'est-à-dire de produire automatiquement des rapports d'avancement à partir de vos spécifications exécutables, consiste à donner un feedback aux parties prenantes.

Une autre partie du BDD maintenant, où il devient véritablement quelque chose qui incorpore le TDD dans le cadre d'un processus plus vaste, sont les éléments d'élicitation des éléments. Des idées telles que l'injection de fonctionnalités, la cartographie d'impact et les options réelles font partie de ce côté.

Pour la réponse canonique à ce sujet, il serait peut-être préférable de retourner à Dan North . Si votre équipe est composée uniquement de développeurs, alors BDD = TDD. Si votre équipe implique un large éventail de parties prenantes, BDD est plus proche de XP, TDD en faisant partie.


2

Quelle est la relation entre BDD et TDD?

Ce sont les mêmes choses.

D'après ce que j'ai compris, BDD ajoute deux choses principales par rapport à TDD: nommer les tests (s'assurer / devrait)

Ce n'est pas vraiment quelque chose que BDD "ajoute". C'est juste une convention différente qui vise à faciliter l'enseignement et la compréhension du TDD.

Les gens qui ont créé BDD enseignaient tous le TDD, et ils ont remarqué que la chose la plus difficile à comprendre était que le TDD n'avait absolument rien à voir avec les tests. Une fois que les élèves ont surmonté cet obstacle, cela est devenu beaucoup plus facile pour eux. Mais, il est très difficile de se dissocier de la réflexion sur les tests , lorsque le mot «test» (ou une terminologie connexe telle que «affirmer») apparaît pratiquement partout . Alors, ils ont échangé quelques mots.

Mais ce ne sont que les mots! Il n'y a aucune différence réelle entre TDD et BDD.

et les tests d'acceptation.

Les tests d'acceptation sont tout aussi importants pour TDD que pour BDD. Encore une fois: il n'y a pas de différence entre TDD et BDD: TDD bien fait est BDD, BDD est TDD bien fait.


En quoi les tests d'acceptation sont-ils une partie importante du TDD?
SiberianGuy

@Idsa: ils sont importants en ce que votre code ne doit pas passer les tests que vous pensez qu'ils doivent passer, mais ceux que le code est censé faire. Je pense que trop de gens sont confus par cela, que la plupart des tests unitaires sont de bas niveau et évitent ainsi le problème difficile de tester ce que le système a été écrit pour faire globalement.
gbjbaanb

@Idsa: De la même manière qu'ils sont importants pour BDD, bien sûr, car les deux sont la même chose ! Les tests d'acceptation pilotent le cycle externe de TDD, celui qui traite des fonctionnalités et des utilisateurs, par opposition au cycle interne plus détaillé qui traite des API et des protocoles et autres. Je pense que Kent Beck appelle cela "Zoom avant / Zoom arrière". Vous pouvez, par exemple, le voir facilement dans la suite de tests JUnit, qui contient probablement au moins autant de tests d'acceptation qu'il contient de tests unitaires.
Jörg W Mittag

Les tests d'acceptation sont une partie importante du TDD et du BDD. Mais dire que BDD est égal à TDD revient à dire que TDD est égal à test en premier. À moins que vous ne permettiez aux tests de piloter votre code, vous ne faites pas TDD (j'avais l'habitude de connaître quelqu'un qui était heureux d'écrire des tests à l'avance mais qui soutenait que le code devrait toujours être écrit comme il le serait si vous n'écriviez pas l'unité tests et que les tests doivent être rédigés en conséquence). De même, sauf si vous autorisez le comportement à conduire vos tests, vous ne faites pas de BDD.
pdr

1
@Idsa: Notez qu'il existe de nombreuses descriptions erronées de TDD, qui n'incluent pas de tests d'acceptation. Ces descriptions, malheureusement assez populaires et assez largement enseignées, sont l'une des raisons pour lesquelles les gens du BDD ont pensé que ce pourrait être une bonne idée de renommer TDD sous un nom différent, pour éviter la confusion. Néanmoins, et cela ne peut pas être répété assez souvent, TDD et BDD sont exactement la même chose .
Jörg W Mittag
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.