Was sind die Hauptunterschiede zwischen TDD und BDD?

https://stackoverflow.com/questions/2509

08-06-2019
|

Frage

Testgetriebene Entwicklung ist in den letzten Jahren in der .NET-Community in Mode gekommen.Kürzlich habe ich in der ALT.NET-Community Unmut über BDD gehört.Was ist es?Was unterscheidet es von TDD?

Lösung

Ich verstehe, dass es bei BDD mehr darum geht Spezifikation als testen.Es ist mit Domain Driven Design verknüpft (lieben Sie diese *DD-Akronyme nicht?).

Es ist mit einer bestimmten Art und Weise verbunden, User Stories zu schreiben, einschließlich Tests auf hoher Ebene.Ein Beispiel von Tom ten 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 führt Tom diese Testspezifikation direkt in Ruby aus.)

Der Papst von BDD ist Dan North.Eine tolle Einführung finden Sie in ihm Einführung von BDD Artikel.

Einen Vergleich von BDD und TDD finden Sie hier Video.Auch eine Meinung zu BDD als „TDD richtig gemacht“ von Jeremy D.Müller

Aktualisierung vom 25. März 2013

Das obige Video fehlt seit einiger Zeit.Hier ist ein aktuelles von Llewellyn Falco: BDD vs. TDD (erklärt).Ich finde seine Erklärung klar und auf den Punkt gebracht.

Andere Tipps

Für mich liegt der Hauptunterschied zwischen BDD und TDD im Fokus und in der Formulierung.Und Worte sind wichtig, um Ihre Absicht zu kommunizieren.

TDD konzentriert sich auf das Testen.Und da in der „alten Wasserfallwelt“ Tests nach der Implementierung erfolgen, führt diese Denkweise zu falschem Verständnis und Verhalten.

BDD lenkt den Fokus auf Verhalten und Spezifikation, sodass Wasserfallgeister abgelenkt werden.Daher lässt sich BDD leichter als Entwurfspraxis und nicht als Testpraxis verstehen.

Es scheint zwei Arten von BDD zu geben.

Der erste ist der ursprüngliche Stil, den Dan North bespricht und der zur Entstehung der xBehave-Stil-Frameworks führte.Für mich ist dieser Stil in erster Linie für Akzeptanztests oder Spezifikationen für Domänenobjekte anwendbar.

Der zweite Stil wurde von Dave Astels populär gemacht und ist für mich eine neue Form von TDD, die einige ernsthafte Vorteile bietet.Es konzentriert sich eher auf das Verhalten als auf das Testen und auch auf kleine Testklassen und versucht, an den Punkt zu gelangen, an dem Sie im Grunde eine Zeile pro Spezifikations-(Test-)Methode haben.Dieser Stil eignet sich für alle Testebenen und kann mit jedem vorhandenen Unit-Test-Framework durchgeführt werden. Neuere Frameworks (xSpec-Stil) helfen jedoch dabei, sich eher auf das Verhalten als auf das Testen zu konzentrieren.

Es gibt auch eine BDD-Gruppe, die für Sie nützlich sein könnte:

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

Testgetriebene Entwicklung ist eine Test-First-Softwareentwicklungsmethode, was bedeutet, dass Testcode geschrieben werden muss, bevor der eigentliche Code geschrieben wird, der getestet werden soll.In Kent Becks Worten:

Der Stil hier besteht darin, ein paar Codezeilen zu schreiben, dann einen Test, der ausgeführt oder sogar besser ausführen sollte, um einen Test zu schreiben, der nicht ausgeführt wird, und dann den Code schreiben sollte, der ihn zum Laufen bringt.

Nachdem wir herausgefunden haben, wie man ein kleines Stück Code schreibt, möchten wir jetzt ein sofortiges Feedback erhalten und "Code ein wenig, ein wenig testen, ein wenig testen, ein wenig testen". Also schreiben wir sofort einen Test dafür.

TDD ist also eine technische Low-Level-Methode, mit der Programmierer sauberen Code erstellen, der funktioniert.

Verhaltensgesteuerte Entwicklung ist eine Methodik, die auf der Grundlage von TDD erstellt wurde, sich jedoch zu einem Prozess entwickelt hat, der nicht nur Programmierer und Tester betrifft, sondern sich stattdessen mit dem gesamten Team und allen wichtigen Stakeholdern, technischen und nichttechnischen, befasst.BDD ging von ein paar einfachen Fragen aus, die TDD nicht gut beantwortete:Wie viele Tests soll ich schreiben?Was sollte ich eigentlich testen – und was nicht?Welche der Tests, die ich schreibe, sind tatsächlich wichtig für das Unternehmen oder für die Gesamtqualität des Produkts, und welche sind nur meine Überentwicklung?

Wie Sie sehen, erfordern solche Fragen eine Zusammenarbeit zwischen Technologie und Business.Geschäftsinteressenten und Fachexperten können Ingenieuren häufig sagen, welche Art von Tests sinnvoll erscheinen – allerdings nur, wenn es sich bei den Tests um Tests auf hohem Niveau handelt, die sich mit wichtigen Geschäftsaspekten befassen.BDD nennt solche geschäftsähnlichen Tests „Beispiele“, wie etwa „Sagen Sie mir ein Beispiel dafür, wie sich diese Funktion korrekt verhalten sollte“ und reserviert das Wort „Test“ für technische Prüfungen auf niedriger Ebene wie Datenvalidierung oder das Testen von API-Integrationen.Der wichtige Teil ist, dass während Tests kann nur von Programmierern und Testern erstellt werden, Beispiele können vom gesamten Lieferteam – von Designern, Analysten usw. – gesammelt und analysiert werden.

In einem Satz eine der besten Definitionen von BDD, die ich habe gefunden Bisher geht es bei BDD darum, „Gespräche mit Domänenexperten zu führen und Beispiele zu verwenden, um ein gemeinsames Verständnis des gewünschten Verhaltens zu erlangen und Unbekannte zu entdecken“. Der Entdeckungsteil ist sehr wichtig.Je mehr Beispiele das Lieferteam sammelt, desto besser versteht es den Geschäftsbereich und verringert so seine Unsicherheit über einige Aspekte des Produkts, mit dem es sich befassen muss.Mit abnehmender Unsicherheit nehmen Kreativität und Autonomie des Lieferteams zu.Sie können jetzt beispielsweise damit beginnen, eigene Beispiele vorzuschlagen, die die Geschäftsanwender aufgrund mangelnder technischer Fachkenntnisse nicht für möglich gehalten hätten.

Gespräche mit Geschäfts- und Fachexperten zu führen, hört sich großartig an, aber wir alle wissen, wie oft das in der Praxis endet.Ich habe meine Reise in die Technik als Programmierer begonnen.Als Programmierer wird uns das beigebracht Code schreiben–Algorithmen, Designmuster, Abstraktionen.Oder, wenn Sie Designer sind, wird Ihnen das beigebracht Design– Informationen organisieren und schöne Schnittstellen erstellen.Aber wenn wir unsere Einstiegsjobs bekommen, erwarten unsere Arbeitgeber, dass wir "den Kunden einen Mehrwert liefern". Und unter diesen Kunden können zum Beispiel ...eine Bank.Aber ich wusste so gut wie nichts über Bankgeschäfte – außer, wie ich meinen Kontostand effizient verringern konnte.Ich müsste also irgendwie das, was von mir erwartet wird, in Code übersetzen ...Ich müsste eine Brücke zwischen dem Bankgeschäft und meinem technischen Fachwissen schlagen, wenn ich einen Mehrwert liefern möchte.BDD hilft mir, eine solche Brücke auf einem stabilen Fundament einer reibungslosen Kommunikation zwischen dem Bereitstellungsteam und den Fachexperten zu bauen.

Erfahren Sie mehr

Wenn Sie mehr über BDD lesen möchten, habe ich ein Buch zu diesem Thema geschrieben. „Großartige Spezifikationen schreiben“ erforscht die Kunst der Anforderungsanalyse und hilft Ihnen zu lernen, wie Sie einen großartigen BDD-Prozess aufbauen und Beispiele als Kernbestandteil dieses Prozesses verwenden.Das Buch spricht über die allgegenwärtige Sprache, das Sammeln von Beispielen und das Erstellen sogenannter ausführbarer Spezifikationen (automatisierte Tests) aus den Beispielen – Techniken, die BDD-Teams dabei helfen, großartige Software pünktlich und im Rahmen des Budgets bereitzustellen.

Wenn Sie daran interessiert sind, „Writing Great Specifications“ zu kaufen, Sie können 39 % sparen mit dem Promo-Code 39nicieja2 :)

Ich habe ein wenig mit dem BDD-Ansatz experimentiert und komme zu dem voreiligen Schluss, dass BDD gut für die Anwendungsfallimplementierung geeignet ist, allerdings nicht in Bezug auf die zugrunde liegenden Details.TDD rockt immer noch auf diesem Niveau.

BDD wird auch als Kommunikationsmittel verwendet.Ziel ist es, ausführbare Spezifikationen zu schreiben, die für die Fachexperten verständlich sind.

Es scheint mir, dass BDD einen breiteren Anwendungsbereich hat.Es impliziert fast, dass TDD verwendet wird, dass BDD die umfassende Methodik ist, die die Informationen und Anforderungen unter anderem für die Verwendung von TDD-Praktiken sammelt, um schnelles Feedback sicherzustellen.

Mit meinen neuesten Erkenntnissen über BDD im Vergleich zu TDD konzentriert sich BDD darauf, anzugeben, was als nächstes passieren wird, während sich TDD darauf konzentriert, eine Reihe von Bedingungen einzurichten und dann die Ausgabe zu betrachten.

Verhaltensgesteuerte Entwicklung scheint sich mehr auf die Interaktion und Kommunikation zwischen Entwicklern sowie zwischen Entwicklern und Testern zu konzentrieren.

Der Wikipedia-Artikel hat eine Erklärung:

Verhaltensgesteuerte Entwicklung

Allerdings praktiziere ich selbst kein BDD.

Betrachten Sie den Hauptvorteil von TDD als Design.Es sollte Test Driven Design heißen.BDD ist eine Teilmenge von TDD, nennen wir es Behavior Driven Design.

Betrachten Sie nun eine beliebte Implementierung von TDD – Unit Testing.Die Einheiten beim Unit-Testen sind typischerweise ein Bit Logik, also die kleinste Arbeitseinheit, die Sie erstellen können.

Wenn Sie diese Einheiten auf funktionale Weise zusammenfügen, um das gewünschte Verhalten gegenüber den Maschinen zu beschreiben, müssen Sie das Verhalten verstehen, das Sie gegenüber der Maschine beschreiben.Verhaltensgesteuertes Design konzentriert sich auf die Überprüfung des Verständnisses der Implementierer für die Anwendungsfälle/Anforderungen/was auch immer und überprüft die Implementierung jeder Funktion.BDD und TDD dienen im Allgemeinen dem wichtigen Zweck, das Design zu informieren, und dem zweiten Zweck, die Korrektheit der Implementierung zu überprüfen, insbesondere wenn sie sich ändert.Richtig durchgeführtes BDD umfasst Biz und Entwicklung (und Qualitätssicherung), während Unit-Tests (möglicherweise fälschlicherweise als TDD und nicht als eine Art von TDD angesehen) normalerweise im Entwicklungssilo durchgeführt werden.

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

BDD ist weitgehend TDD, richtig gemacht.BDD bietet jedoch noch einen weiteren Mehrwert.Hier ist ein Link dazu:

BDD ist mehr als „TDD richtig gemacht“

Hier ist der kurze Schnappschuss:

TDD ist lediglich der Prozess des Testens von Code vor dem Schreiben!

DDD ist der Prozess, bei dem vor jedem Code-Berührungszyklus über die Domain informiert wird!

BDD ist eine Implementierung von TDD, die einige Aspekte von DDD einbezieht!

Hoffentlich hilft das!

Unterschied zwischen testgetriebener Entwicklung (TDD) und verhaltensgetriebener Entwicklung (BDD)

BDD konzentriert sich eher auf den Verhaltensaspekt des Systems als auf den
Implementierungsaspekt des Systems, auf den sich TDD konzentriert.
BDD vermittelt ein klareres Verständnis darüber, was das System tun soll
aus der Sicht des Entwicklers und des Kunden.Nur TDD
gibt dem Entwickler ein Verständnis dafür, was das System tun soll.
BDD ermöglicht es sowohl dem Entwickler als auch dem Kunden, zusammen zu arbeiten, um die Anforderungsanalyse im Quellcode des Systems zu finden.

Es gibt keinen Unterschied zwischen TDD und BDD.außer dass Sie Ihre Tests besser lesen und als Anforderungen verwenden können.Wenn Sie Ihre Anforderungen mit den gleichen Worten formulieren, wie Sie BDD-Tests schreiben, können Sie von Ihrem Kunden mit einigen Ihrer definierten Tests zum Schreiben von Code kommen.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow