Relation entre BDD et TDD

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?

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.

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.

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.

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.