Was sind die wichtigsten Unterschiede zwischen TDD und BDD?

stimmen
119

Test Driven Development der letzte Schrei in der .NET-Community in den letzten paar Jahren. Vor kurzem habe ich Murren in der ALT.NET Gemeinschaft über BDD gehört. Was ist es? Was unterscheidet sie von TDD?

Veröffentlicht am 05/08/2008 um 16:58
quelle vom benutzer
In anderen Sprachen...                            


15 antworten

stimmen
94

Ich verstehe BDD mehr über seine Spezifikation als Test . Es ist mit Domain Driven Design (nicht tun Sie diese Liebe * DD Abkürzungen?).

Es ist mit einer bestimmten Art und Weise verknüpft Benutzergeschichten zu schreiben, einschließlich High-Level - Tests. Ein Beispiel von Tom zehn 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

(In seinem Artikel Tom geht direkt in Ruby diese Testspezifikation auszuführen.)

Der Papst von BDD ist Dan Nord . Sie werden eine großartige Einführung in seinen finden Einführung BDD Artikel.

Sie werden einen Vergleich von BDD und TDD in diesem finden Video . Auch eine Meinung zu BDD als „TDD richtig gemacht“ von Jeremy D. Miller

25. März 2013 Update

Das Video oben wurde für eine Weile fehlen. Hier ist jüngeren Datums von Llewellyn Falco, BDD vs TDD (erklärt) . Ich finde seine Erklärung klar und auf den Punkt.

Beantwortet am 05/08/2008 um 17:36
quelle vom benutzer

stimmen
17

Für mich primären Unterschied zwischen BDD und TDD ist Fokus und Formulierung. Und Worte sind wichtig für Ihre Absicht zu kommunizieren.

TDD-Adresse verweist auf Tests konzentrieren. Und da in „alte Wasserfall Welt“ Tests kommen nach der Implementierung, dann ist diese Einstellung zu falschem Verständnis und Verhalten führt.

BDD-Adresse verweist auf das Verhalten und Spezifikation konzentrieren, und so Wasserfall Geist abgelenkt sind. So wird BDD leichter als Design-Praxis verstanden und nicht als Testpraxis.

Beantwortet am 08/09/2008 um 19:36
quelle vom benutzer

stimmen
13

Es scheint zwei Arten von BDD zu sein.

Der erste ist der ursprüngliche Stil, Dan Nord diskutiert und die die Schaffung der xBehave Stil Rahmenbedingungen verursacht. Für mich ist dieser Stil in erster Linie anwendbar für die Abnahmeprüfung oder Spezifikationen gegen Domain-Objekte.

Die zweite Art ist das, was Dave Astels populär gemacht und das, zu mir, ist eine neue Form von TDD, die einige gravierende Vorteile. Es konzentriert sich auf das Verhalten eher als Test und auch kleine Testklassen, auf den Punkt zu bringen versuchen, wo Sie im Grunde eine Zeile pro Spezifikation (Test) Methode haben. Dieser Stil eignet sich für alle Teststufen und können mit jedem bestehenden Unit Testing Framework getan werden, obwohl neuere Frameworks (xSpec Stil) eher man das Verhalten konzentrieren helfen als Tests.

Es gibt auch eine BDD-Gruppe, die Ihnen nützlich sein könnten:

http://groups.google.com/group/behaviordrivendevelopment/

Beantwortet am 10/09/2008 um 17:00
quelle vom benutzer

stimmen
6

Ich habe ein wenig mit dem BDD Ansatz experimentiert und meine vorzeitige Schlussfolgerung ist, dass BDD gut geeignet ist Fall Implementierung zu verwenden, aber nicht auf den zugrunde liegenden Details. TDD noch auf diesem Niveau rocken.

BDD wird auch als Kommunikationsmittel verwendet wird. Ziel ist es, ausführbare Spezifikationen zu schreiben, die von den Domain-Experten verstanden werden können.

Beantwortet am 27/08/2008 um 21:59
quelle vom benutzer

stimmen
5

Testgetriebene Entwicklung ist eine Test-First - Software - Entwicklungsmethodik, was bedeutet , dass es Testcode zu schreiben , bevor den eigentlichen Code zu schreiben , die getestet werden muß. In Kent Becks Worten:

Der Stil ist hier ein paar Zeilen Code zu schreiben, dann ein Test, der ausgeführt werden soll, oder noch besser, einen Test zu schreiben, die nicht ausgeführt wird, dann den Code schreiben, der es laufen wird machen.

Nach herauszufinden, wie ein kleines Stück Code zu schreiben, jetzt, statt nur Codierung auf, wollen wir ein unmittelbares Feedback und Praxis bekommen „Code ein wenig, testen ein wenig, Code ein wenig, testen ein wenig.“ So schreiben wir sofort einen Test dafür.

So ist TDD ein Low-Level-technische Methode, die Programmierer verwenden, um sauberen Code zu produzieren, das funktioniert.

Verhalten-Driven Development ist eine Methodik , die basierend auf TDD erstellt wurde, sondern entwickelte sich zu einem Prozess, betrifft nicht nur Programmierer und Tester, sondern befasst sich mit dem gesamten Team und allen wichtigen Interessengruppen, technische und nicht-technische. BDD begann aus einem paar einfachen Fragen , die TDD antwortet nicht gut: wie viele Tests soll ich schreiben? Was soll ich testen-und eigentlich das, was soll ich nicht? Welche der Tests wird ich schreiben sein in der Tat wichtig für das Unternehmen oder auf die Gesamtqualität des Produkts und das ist nur mein Over-Engineering?

Wie Sie sehen können, benötigen solche Fragen der Zusammenarbeit zwischen Technologie und Wirtschaft. Stakeholder und Domain - Experten können oft Ingenieure sagen , welche Art von Tests klingen wie sie nützlich, aber wären nur , wenn die Tests sind High-Level - Tests , die mit wichtigen betriebswirtschaftlichen Aspekten beschäftigen. BDD nennt solche Business-like - Tests „Beispiele“ , wie in „sagen Sie mir ein Beispiel, wie diese Funktion richtig verhalten sollte“ , und behält sich das Wort „Test“ für Low-Level, Integrationen technische Kontrollen wie die Datenüberprüfung oder Prüfung API. Der wichtigste Teil ist , dass , während Tests können nur von Programmierern und Testern erstellt werden, Beispiele können durch die gesamte Lieferung Team von Designern, Analysten gesammelt und analysiert werden, und so weiter.

In einem Satz, einer der besten Definitionen von BDD Ich habe gefunden , so weit ist , dass BDD ist über „mit Gesprächen mit Fachexperten und anhand von Beispielen ein gemeinsames Verständnis des gewünschten Verhalten zu gewinnen und Unbekannten entdecken.“ Der Teil Entdeckung ist sehr wichtig , . Da die Lieferung Team weitere Beispiele sammelt, beginnen sie die Business - Bereich mehr und mehr zu verstehen und somit reduzieren sie ihre Unsicherheit über einige Aspekte des Produkts müssen sie beschäftigen. Wie Unsicherheit abnimmt, Kreativität und Autonomie des Zuwachses Lieferung Team. Zum Beispiel können sie nun ihre eigenen Beispiele was darauf hindeutet , dass der Business - Anwender wegen ihres Mangels an Tech - Know - how nicht glaubte , möglich war.

Nun klingt Gespräche mit den Unternehmen und Domain - Experten, die große, aber wir alle wissen , wie das in der Praxis oft endet. Ich begann meine Reise mit Tech als Programmierer. Als Programmierer, werden wir gelehrt Code schreiben -algorithms, Design Patterns, Abstraktionen. Oder, wenn Sie ein Designer sind, werden Sie gelehrt zu entwerfen-Organisieren Informationen und schöner Schnittstellen erstellen. Aber wenn wir unsere Einsteigerjobs bekommen, unsere Arbeitgeber erwarten, dass wir zu „liefern Mehrwert für die Kunden.“ Und unter diesen können Kunden, zum Beispiel ... eine Bank. Aber ich konnte wissen so gut wie nichts über Banking-Ausnahme, wie effizient Gleichgewicht meines Kontos zu verringern. So würde ich muss irgendwie übersetzen, was mir in den Code zu erwarten ist ... Ich muss eine Brücke zwischen Banken und mein technisches Know-how bauen würde, wenn ich einen Wert liefern wollen. BDD hilft mir, auf eine stabile Grundlage für eine Fluidverbindung zwischen dem Förderteam und den Domain-Experten, eine solche Brücke zu bauen.

Mehr erfahren

Wenn Sie mehr über BDD lesen wollen, schrieb ich ein Buch über das Thema. „Writing Große Spezifikationen“ erforscht die Kunst der Analyse Anforderungen und helfen Ihnen lernen , wie man einen großen BDD Prozess zu bauen und Beispiele als Kern Teil dieses Prozesses verwenden. Das Buch spricht über die allgegenwärtige Sprache, Beispiele zu sammeln, und so genannte ausführbare Spezifikationen (automatisierte Tests) aus den Beispielen-Techniken zu schaffen , die BDD - Teams helfen liefern große softeware pünktlich und im Rahmen des Budgets.

Wenn Sie sich für den Kauf sind „Writing Große Spezifikationen“ können Sie 39% sparen mit dem Gutscheincode 39nicieja2 :)

Beantwortet am 12/02/2017 um 16:43
quelle vom benutzer

stimmen
2

Betrachten Sie den Hauptvorteil der TDD-Design zu sein. Es sollte Test-Driven Design bezeichnet werden. BDD eine Teilmenge von TDD ist, nennen es Behavior Driven Design.

Betrachten wir nun eine populäre Implementierung von TDD - Unit Testing. Die Anteile in Unit-Tests sind in der Regel ein wenig Logik, die die kleinste Einheit der Arbeit ist, kann man machen.

Wenn Sie diese Einheiten zusammen in einer funktionalen Weise stellen das gewünschte Verhalten zu den Maschinen zu beschreiben, müssen Sie das Verhalten verstehen, an die Maschine zu beschreiben sind. Verhalten Driven Design konzentriert sich auf das Verständnis der Implementierer Überprüfung der Use Cases / Anforderungen / was auch immer und überprüft die Umsetzung der einzelnen Funktion. BDD und TDD im Allgemeinen dient dem wichtigen Zweck Design der Information und den zweiten Zweck, die Korrektheit der Implementierung überprüfen, vor allem, wenn sie sich ändert. BDD richtig gemacht beinhaltet biz und Entwickler (und qa), während Unit Testing (möglicherweise falsch als TDD betrachtet eher als eine Art von TDD) wird typischerweise in dev Silo getan.

Ich möchte hinzufügen, dass BDD Tests als Lebensanforderungen dienen.

Beantwortet am 28/05/2015 um 22:36
quelle vom benutzer

stimmen
2

BDD ist weitgehend TDD richtig gemacht. Allerdings gibt es einen Mehrwert, dass BDD bietet. Hier ist ein Link auf das:

BDD ist mehr als „TDD richtig gemacht“

Beantwortet am 29/07/2010 um 11:25
quelle vom benutzer

stimmen
2

Mit meinem neuesten Erkenntnissen in BDD wenn TDD verglichen, konzentriert sich BDD auf die festlegen, was als nächstes passieren wird, während TDD auf eine Reihe von Bedingungen Einrichtung konzentriert und dann am Ausgang suchen.

Beantwortet am 25/05/2009 um 05:09
quelle vom benutzer

stimmen
2

Es scheint mir, dass BDD ein breiterer Anwendungsbereich ist. Es impliziert fast TDD verwendet wird, dass BDD die encompasing Methodik ist, dass die Informationen und Anforderungen für die Verwendung, amongh andere Dinge sammelt, TDD Praktiken schnelles Feedback zu gewährleisten.

Beantwortet am 05/08/2008 um 17:11
quelle vom benutzer

stimmen
2

Verhalten Driven Development scheint mehr auf der Interaktion und Kommunikation zwischen Entwicklern und auch zwischen Entwicklern und Testern zu konzentrieren.

Der Wikipedia-Artikel hat eine Erklärung:

Verhalten-Driven Development

wenn auch nicht selbst zu praktizieren BDD.

Beantwortet am 05/08/2008 um 17:06
quelle vom benutzer

stimmen
1

Der Unterschied zwischen Test-Driven Development (TDD) und verhaltensgetriebene Entwicklung (BDD)

  • BDD konzentriert sich auf dem Verhaltensaspekt des Systems statt der
    Umsetzung Aspekte des Systems, das TDD konzentriert sich auf.

  • BDD gibt ein besseres Verständnis darüber, was das System tun soll
    aus der Sicht des Entwicklers und dem Kunden. TDD nur
    gibt dem Entwickler ein Verständnis von dem, was das System tun soll.

  • BDD ermöglicht sowohl den Entwickler und den Kunden gemeinsam auf der Anforderungsanalyse zu arbeiten, die im Quellcode des Systems enthalten ist.

Beantwortet am 09/06/2017 um 23:49
quelle vom benutzer

stimmen
1

Hier ist der Schnappschuss:

  • TDD ist nur den Prozess des Testcode, bevor es zu schreiben!

  • DDD ist der Prozess der des Berührens Code vor jedem Zyklus über die Domain informiert zu werden!

  • BDD ist eine Implementierung von TDD, die in einigen Aspekten von DDD bringt!

Ich hoffe, das hilft!

Beantwortet am 18/01/2016 um 03:01
quelle vom benutzer

stimmen
0

Die Wahl zwischen TDD und BDD ist kompliziert. Es hängt davon ab, ob es ein geeigneter Test-Framework für Ihre gegebene Zielsprache ist, was Ihre Mitarbeiter sind komfortabel mit, und manchmal auch andere Faktoren.

Einige argumentieren, dass BDD ist immer besser als TDD, weil es die Möglichkeit der Aufhebung Probleme hat, die entstehen könnten, wenn TDD.

Der Schlüssel zu BDD ist, dass es Probleme verhindern könnte; es ist nicht garantiert. Probleme wie schlechte Code-Organisation, schlechte Design Praktiken, etc. werden nach wie vor bestehen. Sie müssen nur eine geringere Wahrscheinlichkeit Haube schlecht Tests schreiben und haben somit robuste Funktionen.

Beantwortet am 18/09/2016 um 09:59
quelle vom benutzer

stimmen
0

Es gibt keinen Unterschied betwen TDD und BDD. außer Sie können Ihre Tests besser, und Sie können sie als Anforderungen verwenden lesen. Wenn Sie Ihre Anforderungen mit den gleichen Worten schreiben, wie Sie BDD Tests schreiben, dann können Sie kommen, um Ihre Klienten frome mit einigen Ihrer Tests bereit definierten Code zu schreiben.

Beantwortet am 07/10/2014 um 09:52
quelle vom benutzer

stimmen
-1

Dieser Blog bietet eine interessante Sicht auf die Unterschiede zwischen TDD, BDD und ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

Beantwortet am 20/05/2014 um 19:32
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more