Quelles sont les principales différences entre TDD et BDD ?
https://stackoverflow.com/questions/2509
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
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 ?
La solution
Je comprends que BDD concerne davantage spécification que essai.Il est lié au Domain Driven Design (vous n'aimez pas ces acronymes *DD ?).
Cela est lié à une certaine manière d’écrire des user stories, notamment des tests de haut niveau.Un exemple par Tom dix 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 exécute directement cette spécification de test dans Ruby.)
Le pape du BDD est Dan Nord.Vous trouverez une excellente introduction dans son Présentation de BDD article.
Vous trouverez une comparaison de BDD et TDD dans ce vidéo.Également un avis sur BDD comme "TDD bien fait" par Jérémie D.Meunier
Mise à jour du 25 mars 2013
La vidéo ci-dessus a disparu depuis un moment.En voici un récent de Llewellyn Falco, BDD vs TDD (expliqué).Je trouve son explication claire et pertinente.
Autres conseils
Pour moi, la principale différence entre BDD et TDD réside dans l'orientation et la formulation.Et les mots sont importants pour communiquer votre intention.
TDD se concentre sur les tests.Et comme dans « l’ancien monde des cascades », les tests surviennent après la mise en œuvre, 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 évoqué par 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 de domaine.
Le deuxième style est celui 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 également sur les petites classes de tests, 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 tests et peut être effectué à l'aide de n'importe quel framework de tests unitaires existant, bien que des frameworks plus récents (style xSpec) aident à se concentrer sur le comportement plutôt que sur les tests.
Il existe également un groupe BDD qui pourrait vous être utile :
Développement piloté par les tests est une méthodologie de développement logiciel axée sur les tests, ce qui signifie qu'elle nécessite l'écriture du code de test avant d'écrire le code réel qui sera testé.Selon les mots de Kent Beck :
Le style ici est d'écrire quelques lignes de code, puis un test qui devrait s'exécuter, ou même mieux, pour écrire un test qui ne s'exécutera pas, puis écrivez le code qui le fera s'exécuter.
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 "Code un peu, tester un peu, coder un peu, tester un peu". Nous écrivons donc immédiatement un test pour cela.
TDD est donc une méthodologie technique de bas niveau que les programmeurs utilisent pour produire du code propre et fonctionnel.
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 seulement les programmeurs et les testeurs, mais qui concerne plutôt l'ensemble de 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 réellement tester et que ne devrais-je pas tester ?Lesquels des tests que j'écris seront en fait importants pour l'entreprise ou pour la qualité globale du produit, et lesquels ne sont que du fait de ma sur-ingénierie ?
Comme vous pouvez le constater, de telles questions nécessitent une collaboration entre la technologie et les entreprises.Les parties prenantes de l'entreprise et les experts du domaine peuvent souvent indiquer aux ingénieurs quels types de tests semblent utiles, mais uniquement s'il s'agit de tests de haut niveau traitant d'aspects commerciaux importants.BDD appelle ces tests professionnels des « exemples », comme dans « dites-moi un exemple de la façon dont cette fonctionnalité devrait se comporter correctement » et réserve le mot « test » aux contrôles techniques de bas niveau tels que la validation des données ou le test des intégrations d'API.L'important est que même si essais ne peut être créé que par des programmeurs et des testeurs, exemples peuvent être collectés et analysés par l’ensemble de 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é Jusqu'à présent, BDD consiste à «avoir des conversations avec des experts du domaine et en utilisant des exemples pour acquérir une compréhension partagée du comportement souhaité et découvrir des inconnues». La partie de découverte est très importante.Au fur et à mesure que l'équipe de livraison collecte davantage d'exemples, elle commence à comprendre de plus en plus le domaine commercial et réduit ainsi son incertitude sur certains aspects du produit avec lequel elle doit traiter.À mesure que l’incertitude diminue, la créativité et l’autonomie de l’équipe de livraison augmentent.Par exemple, ils peuvent désormais commencer à suggérer leurs propres exemples que les utilisateurs professionnels ne pensaient pas possibles en raison de leur manque d’expertise technique.
Aujourd’hui, avoir des conversations avec des experts métier et du domaine semble formidable, 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 à conception—organiser les informations et créer de belles interfaces.Mais lorsque nous obtenons nos emplois d'entrée de gamme, nos employeurs s'attendent à ce que nous «fournissons de la valeur aux clients». Et parmi ces clients peut être, par exemple ...une banque.Mais je ne connaissais presque rien aux opérations bancaires, sauf comment réduire efficacement le solde de mon compte.Il faudrait donc que je traduise d'une manière ou d'une autre ce que l'on attend de moi en code...Je devrais construire un pont entre le secteur bancaire et mon expertise technique si je veux apporter une quelconque 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 souhaitez en savoir plus sur BDD, j'ai écrit un livre sur le sujet. « Rédiger de bonnes spécifications » explore l'art de l'analyse des exigences et vous aidera à apprendre à créer un excellent processus BDD et à utiliser des exemples comme élément essentiel 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 d'excellents logiciels dans les délais et dans les limites du budget.
Si vous souhaitez acheter « Rédaction de grandes spécifications », vous pouvez économiser 39% avec le code promo 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 aux détails sous-jacents.TDD est toujours aussi rock à ce niveau.
BDD est également utilisé comme outil de communication.L'objectif est de rédiger des spécifications exécutables qui peuvent être comprises par les experts du domaine.
Il me semble que BDD a une portée plus large.Cela implique presque que TDD est utilisé, que BDD est la méthodologie globale qui rassemble les informations et les exigences pour l'utilisation, entre autres choses, des pratiques TDD afin de garantir un retour d'information 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, puis sur l'examen du résultat.
Le développement piloté par 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
Cependant, je ne pratique pas le BDD moi-même.
Considérez que le principal avantage du TDD est la conception.Cela devrait s’appeler Test Driven Design.BDD est un sous-ensemble de TDD, appelé Behaviour 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 morceau de logique qui constitue la plus petite unité de travail que vous puissiez créer.
Lorsque vous rassemblez ces unités de manière fonctionnelle pour décrire le comportement souhaité des machines, vous devez comprendre le comportement que vous décrivez à la machine.La conception pilotée par 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 remplissent l'objectif important d'informer la conception et le deuxième objectif de vérifier l'exactitude de la mise en œuvre, en particulier lorsqu'elle change.BDD bien fait implique le business et le développement (et la qualité), tandis que les tests unitaires (peut-être 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 un TDD bien fait.Cependant, BDD offre une valeur supplémentaire.Voici un lien à ce sujet :
Voici un aperçu rapide :
TDD n'est que le processus de test du code avant de l'écrire !
DDD est le processus consistant à être informé du domaine avant chaque cycle de toucher du code !
BDD est une implémentation de TDD qui apporte certains aspects de DDD !
J'espère que cela pourra aider!
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 comportemental du système.
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 uniquement
donne au développeur une compréhension de ce que le système doit faire.BDD permet au développeur et au client de travailler ensemble pour l'analyse des exigences qui est contenue dans le code source du système.
Il n'y a aucune différence entre TDD et BDD.sauf que vous pouvez mieux lire vos tests et les utiliser comme exigences.Si vous écrivez vos exigences avec les mêmes mots que vous écrivez des tests BDD, vous pouvez alors venir de votre client avec certains de vos tests définis, prêts à écrire du code.
