Beziehung zwischen BDD und TDD

30

Wie ist das Verhältnis von BDD und TDD?

Nach meinem Verständnis fügt BDD zwei wichtige Dinge zu TDD hinzu: Benennungstests (Sicherstellen / Sollte) und Abnahmetests. Soll ich TDD während der Entwicklung von BDD folgen? Wenn ja, sollten meine TDD-Komponententests im selben Stil angegeben werden?

SiberianGuy
quelle
1
BDD ist ein Satz gut dokumentierter TDDs (Unitests)
DD
Möchte jemand eine Antwort aus dem Behavior Driven Design Camp hinzufügen ? Aus meiner Sicht handelt es sich bei diesen Antworten um die ersten Iterationen von BDD. Erfolgreiche BDD-Anwendungen befinden sich heutzutage häufig in der Nähe des Designs und können gegebenenfalls sogar vollständig auf automatisierte Tests verzichten.
Paul Hicks
Der Unterschied zwischen BDD und TDD ist wie der Unterschied zwischen Makroökonomie und Mikroökonomie. BDD = Aufbau eines Verständnisses der Anforderungen anhand von Beispielen. Optional können automatisierte Makrotests durchgeführt werden. (agilenoir.biz/de/am-i-behavioral-or-not), TDD = Mikrotests schreiben, um das Schreiben von Codierungen voranzutreiben. Der Agile Thoughts-Podcast behandelt auch diese Unterschiede: agilenoir.biz/de/agilethoughts/test-automation-pyramid-series
Lance Kind

Antworten:

37

BDD fügt einen Zyklus um den TDD-Zyklus hinzu.

Sie beginnen also mit einem Verhalten und lassen das Ihre Tests vorantreiben, dann lassen Sie die Tests die Entwicklung vorantreiben. Im Idealfall wird BDD durch eine Art Abnahmetest gesteuert, dies ist jedoch nicht zu 100% erforderlich. Solange Sie das erwartete Verhalten definiert haben, sind Sie in Ordnung.

Angenommen, Sie schreiben eine Anmeldeseite.

Beginnen Sie mit dem glücklichen Weg:

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

Diese Gegeben-Und-Wenn-Und-Dann-Und-Syntax ist in der verhaltensgetriebenen Entwicklung weit verbreitet. Einer der Vorteile ist, dass es von Nicht-Entwicklern gelesen (und mit Schulung geschrieben) werden kann. Das heißt, Ihre Stakeholder können die Liste der Verhaltensweisen anzeigen, die Sie für den erfolgreichen Abschluss einer Aufgabe definiert haben, und prüfen, ob dies der Fall ist entspricht ihren Erwartungen lange bevor Sie ein unvollständiges Produkt veröffentlichen.

Es gibt eine Skriptsprache namens "Gherkin", die der oben genannten sehr ähnlich ist und es Ihnen ermöglicht, Testcode hinter die Klauseln in diesen Verhaltensweisen zu schreiben. Sie sollten nach einem Gherkin-basierten Übersetzer für Ihr übliches Entwicklungsframework suchen. Das liegt außerhalb des Rahmens dieser Antwort.

Wie auch immer, zurück zum Verhalten. Ihre aktuelle Anwendung tut dies noch nicht (wenn ja, warum fordert jemand eine Änderung an?), Sodass Sie diesen Test nicht bestehen, unabhängig davon, ob Sie einen Testläufer verwenden oder einfach manuell testen.

Jetzt ist es an der Zeit, zum TDD-Zyklus zu wechseln, um diese Funktionalität bereitzustellen.

Unabhängig davon, ob Sie BDD schreiben oder nicht, sollten Ihre Tests eine gemeinsame Syntax haben. Eine der häufigsten ist die von Ihnen beschriebene "sollte" -Syntax.

Schreiben Sie einen Test: ShouldAcceptValidDetails. Durchlaufe den Rot-Grün-Refaktor-Zyklus, bis du damit zufrieden bist. Bestehen wir jetzt den Verhaltenstest? Wenn nicht, schreiben Sie einen weiteren Test: ShouldRedirectToUserDefaultPage. Rot-Grün-Refaktor bis du glücklich bist. Waschen, spülen, wiederholen, bis Sie die im Verhalten festgelegten Kriterien erfüllen.

Und dann gehen wir zum nächsten Verhalten über.

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"

Jetzt hättest du dies nicht vorwegnehmen sollen, um dein früheres Verhalten zu übertreffen. Sie sollten diesen Test an dieser Stelle nicht bestehen. Kehren Sie also zu Ihrem TDD-Zyklus zurück.

Und so weiter, bis Sie Ihre Seite haben.

Wir empfehlen das Rspec Book, um mehr über BDD und TDD zu erfahren, auch wenn Sie kein Ruby-Entwickler sind.

pdr
quelle
Können Sie nur Kommentare abgeben? Ich verstehe es immer noch nicht ...
Honey
4

Mein Verständnis davon:

  • BDD begann mit einer Umbenennung von TDD, um den Fokus auf das Verhalten deutlicher zu machen.
  • Es bietet mehr formale Unterstützung (DSL und Tools), um sich auf das Verhalten und die ausführbaren Spezifikationen zu konzentrieren.
  • BDD kann nun als Obermenge von TDD angesehen werden. Es ist im Laufe der Zeit gewachsen, mehr von der Anforderungserhebungsseite der Dinge zu erfassen, aber dennoch ist die Seite des Entwicklungsprozesses ein zentraler Bestandteil davon.

Also, um den TDD zu adressieren, erledigt der BDD den richtigen Teil. BDD begann mit einem Sprachwechsel von TDD, um die Absicht des Prozesses klar zu machen. Der Einführungsartikel von Dan North über BDD erklärt, warum es sinnvoll ist, sich auf das Wort Verhalten zu konzentrieren und nicht auf Test. Es hilft zu bestätigen, dass Sie nicht nur die richtige Software erstellen, sondern auch die richtige Software. Dies war immer Teil eines guten TDD-Ansatzes, aber Dan hat es ein wenig in BDD kodiert.


Was BDD meiner Meinung nach etwas expliziter macht als TDD oder zumindest formalisiert und Toolunterstützung bietet, ist dieser Zwei-Zyklus- / Doppelschleifen- / Zoom-in-Zoom-out- / Outside-in-Ansatz. Sie beschreiben zunächst das erwartete Verhalten des Features (der äußeren Schleife) und zoomen dann in die innere Schleife hinein, um sich mit den Spezifikationen auf niedriger Ebene zu befassen.

Doubleloop TDD Von http://www.metesreau.com/ncraft-workshop/

Gherkin bietet in Verbindung mit Tools wie Cucumber und SpecFlow die Möglichkeit, diese übergeordneten Feature-Spezifikationen zu schreiben und sie dann mit Code zu verknüpfen, der den Anwendungscode ausführt. Ich würde argumentieren, dass sich BDD hier möglicherweise anders anfühlt als TDD, aber es tut immer noch dasselbe, nur mit etwas zusätzlicher Tool-Unterstützung und DSL. Etwas näher an der traditionellen TDD sind Tools wie rspec, nspec und spock. Diese ähneln ein bisschen mehr dem Vorgang, den Sie bei „herkömmlicher“ TDD ausführen würden, jedoch mit einer stärker verhaltensorientierten Sprache.

In BDD in Action von John Ferguson Smart (sehr empfehlenswert) plädiert er für einen Double-Loop-Ansatz, der mit jBehave auf der äußeren Ebene der ausführbaren Spezifikationen beginnt und sich dann in ein Tool wie Spock für die Low-Level-Spezifikationen verlagert.


BDD bringt das Konzept des Test-Driven den Geschäftsinteressenten näher. Gherkin ist so konzipiert, dass es für Unternehmen lesbar ist. Bei der Idee einer lebendigen Dokumentation, dh automatisch erstellten Fortschrittsberichten aus Ihren ausführbaren Spezifikationen, geht es darum, den Stakeholdern Feedback zu geben.

Ein weiterer Teil von BDD, in dem TDD als Teil eines größeren Prozesses tatsächlich zum Bestandteil von BDD wird, sind die Anforderungen. Ideen wie Feature Injection, Impact Mapping und Real Options sind Teil dieser Seite.

Für die kanonische Antwort darauf ist es vielleicht am besten, noch einmal zu Dan North zu gehen . Wenn Ihr Team ausschließlich aus Entwicklern besteht, ist BDD = TDD. Wenn Ihr Team eine ganze Reihe von Interessengruppen einbezieht, ist BDD näher an XP, wobei TDD ein Teil davon ist.

ngm
quelle
2

Wie ist das Verhältnis von BDD und TDD?

Sie sind das gleiche.

Soweit ich weiß, fügt BDD zwei wichtige Dinge über TDD hinzu: Benennung von Tests (sicherstellen / sollten)

Das ist nicht wirklich etwas, was BDD "hinzufügt". Es ist nur eine andere Konvention, die es einfacher machen soll, TDD zu lehren und zu verstehen.

Die Leute, die BDD erstellt haben, unterrichteten alle TDD und sie stellten fest, dass das Schwierigste zu verstehen war, dass TDD absolut nichts mit Testen zu tun hat. Sobald die Schüler diese Hürde überwunden hatten, fiel es ihnen viel leichter. Aber es ist sehr schwer , sich vom Denken über das Testen zu trennen , wenn das Wort "Test" (oder eine verwandte Terminologie wie "Behauptung") praktisch überall vorkommt . Also wechselten sie ein paar Wörter.

Aber es sind nur die Worte! Es gibt keinen tatsächlichen Unterschied zwischen TDD und BDD.

und Abnahmetests.

Akzeptanztests sind für TDD genauso wichtig wie für BDD. Wieder: Es gibt keinen Unterschied zwischen TDD und BDD: TDD richtig gemacht ist BDD, BDD ist TDD richtig gemacht.

Jörg W. Mittag
quelle
Inwiefern sind Abnahmetests ein wichtiger Bestandteil von TDD?
SiberianGuy
@Idsa: Sie sind wichtig, da Ihr Code nicht die Tests bestehen sollte, von denen Sie glauben, dass sie bestanden werden müssen, sondern die, die der Code ausführen soll. Ich denke, dass zu viele Leute dadurch verwirrt werden, dass die meisten Komponententests niedrig sind und somit das schwierige Problem vermeiden, zu testen, wofür das System insgesamt geschrieben wurde.
gbjbaanb
@Idsa: Genauso wie sie für BDD wichtig sind, natürlich, da die beiden dasselbe sind ! Die Akzeptanztests steuern den äußeren Zyklus von TDD, der sich mit Funktionen und Benutzern befasst, im Gegensatz zum detaillierteren inneren Zyklus, der sich mit APIs und Protokollen und dergleichen befasst. Ich denke, Kent Beck nennt dies "Vergrößern / Verkleinern". Sie können dies beispielsweise in der JUnit-Testsuite leicht erkennen, die wahrscheinlich mindestens so viele Abnahmetests enthält, wie Unit-Tests enthalten.
Jörg W Mittag
Abnahmetests sind ein wichtiger Bestandteil von TDD und BDD. Zu sagen, dass BDD gleich TDD ist, ist vergleichbar damit, dass TDD gleich test-first ist. Wenn Sie nicht zulassen, dass die Tests Ihren Code steuern, führen Sie kein TDD durch (ich kannte früher jemanden, der gerne Tests im Voraus schrieb, aber argumentierte, dass Code immer so geschrieben werden sollte, wie es wäre, wenn Sie keine Unit schreiben würden Tests und diese Tests sollten entsprechend geschrieben werden). Ebenso führen Sie kein BDD durch, es sei denn, Sie gestatten dem Verhalten, Ihre Tests durchzuführen.
pdr
1
@Idsa: Beachten Sie, dass es viele falsche Beschreibungen von TDD gibt, die keine Akzeptanztests enthalten. Diese - leider recht populären und weit verbreiteten - falschen Beschreibungen sind einer der Gründe, warum die BDD-Leute es für eine gute Idee hielten, TDD unter einem anderen Namen umzubenennen, um die Verwirrung zu vermeiden. Trotzdem, und es kann nicht oft genug wiederholt werden, sind TDD und BDD genau dasselbe .
Jörg W Mittag