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.